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CHAPTER  1 
INTRODUCTION 


The  Ada  implementation  described  above  was  tested  according  to  the  Ada  Validation  Procedures 
[Pro90]  against  the  Ada  Standard  [AdaSS]  using  the  current  Ada  Compiler  Validation  Capability 
(ACVC).  This  Validation  Summary  Report  (VSR)  gives  an  account  of  the  testing  of  this  Ada 
implementation.  For  any  technical  terms  used  in  this  report,  the  reader  is  referred  to  [Pro90].  A 
detailed  description  of  the  ACVC  may  be  found  in  the  current  ACVC  User’s  Guide  [UG89]. 


1.1  USE  OF  THIS  VALIDATION  SUMMARY  REPORT 

Consistent  with  the  national  laws  of  the  originating  country,  the  Ada  Certification  Body  may  make 
full  and  free  public  disclosure  of  this  report.  In  the  United  States,  this  is  provided  in  accordance  with 
the  "Freedom  of  Information  Act"  (5  U.S.C.  #552).  The  results  of  this  validation  apply  only  to  the 
computers,  operating  systems,  and  compiler  versions  identified  in  this  report. 

The  organizatioTVS  represented  on  the  signature  page  of  this  report  do  not  represent  or  warrant  that 
all  statements  set  forth  in  this  report  are  accurate  and  complete,  or  that  the  subject  implementation 
has  no  nonconformities  to  the  Ada  Standard  other  than  those  presented.  Copies  of  this  report  are 
available  to  the  public  from  the  AVF  which  performed  this  validation  or  from; 

National  Technical  Information  Service 
5285  Port  Royal  Road 
Springfield  VA  22161 

Questions  regarding  this  report  or  the  validation  test  results  should  be  directed  to  the  AVF  which 
performed  this  validation  or  to: 

Ada  Validation  Organization 

Computer  and  Software  Engineering  Division 

Institute  for  Defense  Analyses 

1801  North  Beauregard  Street 

Alexandria  VA  22311-1772 

1.2  REFERENCES 

[Ada83]  Reference  Manual  for  the  Ada  Programming  Language. 

ANSI/MIL-STD-1815A,  February  1983  and  ISO  8652-1987. 

[Pro90]  Ada  Compiler  Validation  Procedures. 

Version  2.1,  Ada  Joint  Program  Office,  August  1990. 
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[UG89]  Ada  Compiler  Validation  Capability  User's  Guide. 

21  June  1989. 


1.3  ACVC  TEST  CLASSES 

Compliance  of  Ada  implementations  is  tested  by  means  of  the  ACVC.  The  ACVC  contains  a 
collection  of  test  programs  structured  into  six  test  classes:  A,  B,  C,  D,  E,  and  L.  The  first  letter  of  a 
test  name  identifies  the  class  to  which  it  belongs.  Class  A,  C,  D,  and  E  tests  are  executable.  Class  B 
and  class  L  tests  are  expected  to  produce  errors  at  compile  time  and  link  time,  respectively. 

The  executable  tests  are  written  in  a  self-checking  manner  and  produce  a  PASSED,  FAILED,  or 
NOT  APPLICABLE  message  indicating  the  result  when  they  are  executed.  Three  Ada  library  units, 
the  packages  REPORT  and  SPPRT13,  and  the  procedure  CHECK_FILE  are  used  for  this  purpose. 
The  package  REPORT  also  provides  a  set  of  identity  functions  used  to  defeat  some  compiler 
optimizations  allowed  by  the  Ada  Standard  that  would  circumvent  a  test  objective.  The  package 
SPPRT13  is  used  by  many  tests  for  Chapter  13  of  the  Ada  Standard.  The  procedure  CHECK_FILE 
is  used  to  check  the  contents  of  text  files  written  by  some  of  the  Class  C  tests  for  Chapter  14  of  the 
Ada  Standard.  The  operation  of  REPORT  and  CHECK_FILE  is  checked  by  a  set  of  executable  tests. 
If  these  units  are  not  operating  correctly,  validation  testing  is  discontinued. 

Class  B  tests  check  that  a  compiler  detects  illegal  language  usage.  Class  B  tests  are  not  executable. 
Each  tejt  in  this  class  is  compiled  and  the  resulting  compilation  listing  is  examined  to  verify  that  all 
violations  of  the  Ada  Standard  are  detected.  Some  of  the  class  B  tests  contain  legal  Ada  code  which 
must  not  be  flagged  illegal  by  the  compiler.  This  behaviour  is  also  verified. 

Class  L  tests  check  that  an  Ada  implementation  correctly  detects  violation  of  the  Ada  Standard 
involving  multiple,  separately  compiled  units.  Errors  are  expected  at  link  time,  and  execution  is 
attempted. 

In  some  tests  of  the  ACVC,  certain  macro  strings  have  to  be  replaced  by  implementation-specific 
values  -  for  example,  the  largest  integer.  A  list  of  the  values  used  for  this  implementation  is  provided 
in  Appendix  A.  In  addition  to  these  anticipated  test  modifications,  additional  changes  may  be  required 
to  remove  unforeseen  conflicts  between  the  tests  and  implementation-dependent  characteristics.  The 
modifications  required  for  this  implementation  are  described  in  section  2.3. 

• 

For  each  Ada  implementation,  a  customized  test  suite  is  produced  by  the  AVF.  This  customization 
consists  of  making  the  modifications  described  in  the  preceding  paragraph,  removing  withdrawn  tests 
(see  section  2.1),  and  possibly  removing  some  inapplicable  tests  (see  section  2.2  and  [UG89]). 

In  order  to  pass  an  ACVC  an  Ada  implementation  must  process  each  test  of  the  customized  test  suite 
according  to  the  Ada  Standard. 
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1.4  DEHNITION  OF  TERMS 


Ada  Compiler 


Ada  Compiler 
Validation  Capability 
(ACVC) 

Ada  Implementation 


Ada  Joint  Program 
Office  (AJPO) 

Ada  Validation  Facility 
(AVF) 

Ada  Validation 
Organization  (AVO) 

Compliance  of  an  Ada 
Implementation 

Computer  System 


Conformity 

Customer 


Declaration  of 
Conformance 


Host  Computer  System 


The  software  and  any  needed  hardware  that  have  to  be  added  to  a  given 
host  and  target  computer  system  to  allow  transformation  of  Ada 
programs  into  executable  form  and  execution  thereof. 

The  means  for  testing  compliance  of  Ada  implementations,  consisting  of 
the  test  suite,  the  support  programs,  the  ACVC  user’s  guide  and  the 
template  for  the  validation  summary  report. 

An  Ada  compiler  with  its  host  computer  system  and  its  target  computer 
system. 

The  part  of  the  certification  body  which  provides  policy  and  guidance  for 
the  Ada  certification  system. 

The  part  of  the  certification  body  which  carries  out  the  procedures 
required  to  establish  the  compliance  of  an  Ada  implementation. 

The  part  of  the  certification  body  that  provides  technical  guidance  for 
operations  of  the  Ada  certification  system. 

The  ability  of  the  implementation  to  pass  an  ACVC  version. 


A  functional  unit,  consisting  of  one  or  more  computers  and  associated 
software,  that  uses  common  storage  for  all  or  part  of  a  program  and  also 
for  all  or  part  of  the  data  necessary  for  the  execution  of  the  program; 
executes  user-written  or  user-designated  programs;  performs  user- 
designated  date  manipulation,  including  arithmetic  operations  and  logic 
operations;  and  that  can  execute  programs  that  modify  themselves  during 
execution.  A  computer  system  may  be  a  stand-alone  unit  or  may  consist 
of  several  inter-connected  units. 

Fulfilment  of  a  product,  process  or  service  of  all  requirements  specified. 

An  individual  or  corporate  entity  who  enters  into  an  agreement  with  an 
AVF  which  specifies  the  terms  and  conditions  for  AVF  services  (of  any 
kind)  to  be  performed. 

A  formal  statement  from  a  customer  assuring  that  conformity  is  realized 
or  attainable  on  the  Ada  implementation  for  which  validation  status  is 
realized. 

A  computer  system  where  Ada  source  programs  are  transformed  into 
executable  form. 


Validation  Suaaary  Report 


AVF_VSR_90502/79 


SD-Scicon  UK  Liaited 


Chapter  1  -  Page  3  of  4 


XD  Ada  NC68020/ARTX  Version  T1.2 


INTRODUCTION 


Inapplicable  test 

ISO 

LRM 

Operating  System 

Target  Computer 
System 

Validated  Ada  Compiler 

Validated  Ada 
Implementation 

Validation 

Withdrawn  test 


Validation  Suanry  Report 


A  test  that  contains  one  or  more  test  objectives  found  to  be  irrelevant  for 
the  given  Ada  implementation. 

International  Organization  for  Standardization. 

The  Ada  standard,  or  Language  Reference  Manual,  published  as 
ANSI/MIL-STD-1815A-1983  AND  ISO  8652-1987.  Citations  from  the 
LRM  take  the  form  "<section>.<subsection>:<paragraph>." 

Software  that  controls  the  execution  of  programs  and  that  provides 
services  such  as  resource  allocation,  scheduling,  input/output  control  and 
data  management.  Usually,  operating  systems  are  predominantly 
software,  but  partial  or  complete  hardware  implementations  are  possible. 

A  computer  system  where  the  executable  form  of  Ada  programs  are 
executed. 

The  compiler  of  a  validated  Ada  implementation. 

An  Ada  implementation  that  has  been  validated  successfully  either  by 
AVF  testing  or  by  registration  [Pro90]. 

The  process  of  checking  the  conformity  of  an  Ada  compiler  to  the  Ada 
programming  language  and  of  issuing  a  certificate  for  this 
implementation. 

A  test  found  to  be  incorrect  and  not  used  in  conformity  testing.  A  test 
may  be  incorrect  because  it  has  an  invalid  test  objective,  fails  to  meet  its 
test  objective,  or  contains  erroneous  or  illegal  use  of  the  Ada 
programming  language. 
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CHAPTER  2 

IMPLEMENTATION  DEPENDENCIES 


2.1  WITHDRAWN  TESTS 

The  following  tests  have  been  withdrawn  by  the  AVO.  The  rationale  for  withdrawing  each  test  is 
available  from  either  the  AVO  or  the  AVF.  The  publication  date  for  this  list  of  withdrawn  tests  is  2 


August  1991. 

E28005C 

B28006C 

C32202A 

C34006D 

C35508I 

C35508J 

C35508M 

C35508N 

C35702A 

C35702B 

B41308B 

C43004A 

C45114A 

C45346A 

C45612A 

C45612B 

C45612C 

C45651A 

C46022A 

B49008A 

B49008B 

A74006A 

C74308A 

B83022B 

B83022H 

B83025B 

B83025D 

C83026A 

B83026B 

C83041A 

B85001L 

C86001F 

C94021A 

C97116A 

C98003B 

BA2011A 

CB7001A 

CB7001B 

CB7004A 

CC1223A 

BC1226A 

CC1226B 

BC3009B 

BD1B02B 

BD1B06A 

AD1B08A 

BD2A02A 

CD2y\21E 

CD2A23E 

CD2A32A 

CD2A41A 

CD2A41E 

CD2A87A 

CD2B15C 

BD3006A 

BD4008A 

CD4022A 

CD4022D 

CD4024B 

CD4024C 

CD4024D 

CD4031A 

CD4051D 

CD5111A 

CD7004C 

ED7005D 

CD7005E 

AD7006A 

CD7006E 

AD7201A 

AD7201E 

CD7204B 

AD7206A 

BD8002A 

BD8004C 

CD9005A 

CD9005B 

CDA201E 

CE2107I 

CE2117A 

CE2117B 

CE2119B 

CE2205B 

CE2405A 

CE3111C 

CE3116A 

CE3118A 

CE3411B 

CE3412B 

CE3607B 

CE3607C 

CE3607D 

CE3812A 

CE3814A 

CE3902B 

2.2  INAPPLICABLE  TESTS 

A  test  is  inapplicable  if  it  contains  test  objectives  which  are  irrelevant  for  a  given  Ada 
implementation.  Reasons  for  a  test’s  inapplicability  may  be  supported  by  documents  issued  by  the  ISO 
and  the  AJPO  known  as  Ada  Commentaries  and  commonly  referenced  in  the  format  Al-ddddd.  For 
this  implementation,  the  following  tests  were  determined  to  be  inapplicable  for  the  reasons  indicated; 
references  to  Ada  Commentaries  are  included  as  appropriate. 


The  following  159  tests  have  floating-point  type  declarations  requiring  more  digits  than 
SYSTEM.MAX_DIGITS: 


C241130..Y  (11  tests) 
C35706O..Y  (11  tests) 
C35708O..Y  (11  tests) 
C452410..Y  (11  tests) 
C454210..Y  (11  tests) 


C35705O..Y  (11  tests) 
C35707O..Y  (11  tests) 
C35802O..Z  (12  tests) 
C453210..Y  (11  tests) 
C4552IO..Z  (12  tests) 
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C455240..Z  (12  tests)  C456210..Z  (12  tests) 

C456410..Y  (11  tests)  C46012O..Z  (12  tests) 

The  following  20  tests  check  for  the  predefined  type  LONG_INTEGER;  for  this  implementation, 
there  is  no  such  type: 


C35404C 

C45231C 

C45304C 

C45411C 

C45412C 

C45502C 

C45503C 

C45504C 

C45504F 

C45611C 

C45613C 

C45614C 

C45631C 

C45632C 

B52004D 

G55B07A 

B55B09C 

B86001W 

C86006C 

CD7101F 

C35713B,  C45423B,  B86001T,  and  C86006H  check  for  the  predefined  type  SHORT_FLOAT;  for  this 
implementation,  there  is  no  such  type. 

C45423A,  C45523A,  and  C45622A  check  that  the  proper  exception  is  raised  if 

MACHINE_OVERFLOWS  is  TRUE  and  the  results  of  various  floating-point  operations  lie  outside 
the  range  of  the  base  type;  for  this  implementation,  MACHINE_OVERFLOWS  is  FALSE. 

C45531M..P  and  C45532M..P  (8  tests)  check  fixed-point  operations  for  types  that  require  a 
SYSTEM.MAX_MANTISSA  of  47  or  greater;  for  this  implementation,  MAX_MANTISSA  is  less 
than  47. 

B86001Y  uses  the  name  of  a  predefined  fixed-point  type  other  than  type  DURATION;  for  this 
implementation,  there  is  no  such  type. 

C96005B  uses  values  of  type  DURATION’S  base  type  that  are  outside  the  range  of  type 
DURATION;  for  this  implementation,  the  ranges  are  the  same. 

CD1009C  checks  whether  a  length  clause  can  specify  a  non-default  size  for  a  floating-point  type;  this 
implementation  does  not  support  such  sizes. 

CD2A84A,  CD2A84E,  CD2A84I..J  (2  tests),  and  CD2A840  use  length  clauses  to  specify  non-default 
sizes  for  access  types;  this  implementation  does  not  support  such  sizes. 

CD2B15B  checks  that  STORAGE_ERROR  is  raised  when  the  storage  size  specified  for  a  collection 
is  too  small  to  hold  a  single  value  of  the  designated  type;  this  implementation  allocates  more  space 
than  was  specified  by  the  length  clause,  as  allo'ved  by  A1 -00558. 

The  tests  listed  in  the  following  table  check  that  USE_ERROR  is  raised  if  the  given  file  operations 
are  not  supported  for  the  given  combination  of  mode  and  access  method;  this  implementation 
supports  these  operations. 


Test  File  Operation  Mode  File  Access  Method 


CE2102E  CREATE  OUT  HLE  SEQUENTIALJO 

CE2102F  CREATE  INOUT_nLE  DIRECTJO 
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CE2102J 

CREATE 

OUT  FILE 

DIRECT  lO 

CE2102N 

OPEN 

IN  FILE 

SEQUENTIAL  lO 

CE2102O 

RESET 

IN  FILE 

SEQUENTIAL  lO 

CE2102P 

OPEN 

OUT  HLE 

SEQUENTIAL  lO 

CE2102Q 

RESET 

OUT  FILE 

SEQUENTIAL  lO 

CE2102R 

OPEN 

INOUT  RLE 

DIRECT  lO 

CE2102S 

RESET 

INOUT  FILE 

DIRECT  lO 

CE2102T 

OPEN 

IN  FILE 

DIRECT  lO 

CE2102U 

RESET 

IN  RLE 

DIRECT  lO 

CE2102V 

OPEN 

OUT  RLE 

DIRECT  lO 

CE2102W 

RESET 

OUT  FILE 

DIRECT  lO 

CE3102F 

RESET 

Any  Mode 

TEXT  lO 

CE3102G 

DELETE 

TEXT  lO 

CE3102I 

CREATE 

OUT  RLE 

TEXT  lO 

CE3102J 

OPEN 

IN  RLE 

TEXT  lO 

CE3102K 

OPEN 

OUT  RLE 

TEXT  lO 

The  tests  listed  in  the  following  table  check  the  given  file  operations  for  the  given  combination  of 
mode  and  access  method;  this  implementation  does  not  support  these  operations. 


Test  File  Operation  Mode  File  Access  Method 


CE2105A  CREATE  IN  HLE  SEQUENTIAL  lO 

CE2105B  CREATE  IN  FILE  DIRECT  lO 

CE3109A  CREATE  IN"fILE  TEXTJO 

CE2107C..D  (2  tests),  CE2107H,  and  CE2107L  apply  function  NAME  to  temporary  sequential,  direct, 
and  text  files  in  an  attempt  to  associate  multiple  internal  files  with  the  same  external  file; 
USE_ERROR  is  raised  because  temporary  files  have  no  name. 

CE2108B.  CE2108D,  and  CE3112B  use  the  names  of  temporary  sequential,  direct,  and  text  files  that 
were  created  in  other  tests  in  order  to  check  that  the  temporary  files  are  not  accessible  after  the 
completion  of  those  tests;  for  this  implementation,  temporary  files  have  no  name. 

CE2203A  checks  that  WRITE  raises  USE_ERROR  if  the  capacity  of  an  external  sequential  file  is 
exceeded;  this  implementation  cannot  restrict  file  capacity. 

EE2401D  checks  whether  DIRECT_IO  can  be  instantiated  for  an  element  type  that  is  an 
unconstrained  array  type;  this  implementation  raises  USE_ERROR  on  the  attempt  to  create  a  file, 
because  the  maximum  potential  element  size  exceeds  the  implementation  limit  of  2**16-1  bits. 

CE2403A  checks  that  WRITE  raises  USE_ERROR  if  the  capacity  of  an  external  direct  file  is 
exceeded;  this  implementation  cannot  restrict  file  capacity. 
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CE3304A  checks  that  SET_LINE_LENGTH  and  SET_PAGE_LENGTH  raise  USE_ERROR  if 
they  specify  an  inappropriate  value  for  the  external  file;  there  are  no  inappropriate  values  for  this 
implementation. 

CE3413B  checks  that  PAGE  raises  LAYOUT_ERROR  when  the  value  of  the  page  number  exceeds 
COUNT’LAST;  for  this  implementation,  the  value  of  COUNT’LAST  is  greater  than  150000,  making 
the  checking  of  this  objective  impractical. 


2.3  TEST  MODIFICATIONS 

Modifications  (see  section  1.3)  were  required  for  17  tests. 

The  following  tests  were  split  into  two  or  more  tests  because  this  implementation  did  not  report  the 
violations  of  the  Ada  Standard  in  the  way  expected  by  the  original  tests. 

B97103E 

C45524A..K  (11  tests)  were  graded  passed  by  Test  Modification  as  directed  by  the  AVO.  These  tests 
expect  that  a  repeated  division  will  result  in  zero;  but  the  Ada  standard  only  requires  that  the  result 
lie  in  the  smallest  safe  interval.  Thus,  the  tests  were  modified  to  check  that  the  result  was  within  the 
smallest  safe  interval,  by  adding  the  following  code  after  line  141;  the  modified  tests  were  passed: 

ELSIF  VAL  <=  FSAFE_SMALL  THEN  COMMENT  ("UNDERFLOW  IS  GRADUAL"); 

BC3204C,  BC3204D,  BC3205C  and  BC3205D  were  graded  passed  by  Processing  Modification  as 
directed  by  the  AVO.  These  tests  check  that  instantiations  of  generic  units  with  unconstrained  types 
as  generic  actual  parameters  are  illegal  if  the  generic  bodies  contain  uses  of  the  types  that  require 
a  constraint.  However,  the  generic  bodies  are  compiled  after  the  units  that  contain  the  instantiations, 
and  this  implementation  creates  a  dependence  of  the  instantiating  units  on  the  generic  units  as 
allowed  by  AI-00408  and  AI'00506  such  that  the  compilation  of  the  generic  bodies  makes  the 
instantiating  units  obsolete--no  errors  are  detected.  The  processing  of  these  tests  was  modified  by 
re-compiling  the  obsolete  units;  all  intended  errors  were  then  detected  by  the  compiler. 

CE3804H  was  graded  passed  by  Evaluation  Modification  as  directed  by  the  AVO.  This  test  requires 
that  the  string  "-3.525"  can  be  read  from  a  file  using  FLOAT_IO  and  that  an  equality  comparison  with 
the  numeric  literal  ’-3.525’  will  evaluate  to  TRUE;  however,  because  -3.525  is  not  a  model  number, 
this  comparison  may  evaluate  to  FALSE  (LRM  4.9:12).  This  implementation’s  compile-time  and 
run-time  evaluation  algorithms  differ;  thus,  this  check  for  equality  fails  and  Report.Failed  is  called 
at  line  81,  which  outputs  the  message  "WIDTH  CHARACTERS  NOT  READ."  All  other  checks  were 
passed. 
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CHAPTER  3 

PROCESSING  INFORMATION 


3.1  TESTING  ENVIRONMENT 

The  Ada  implementation  tested  in  this  validation  effort  is  described  by  the  information  given  in  the 
initial  pages  of  this  report  together  with  the  following  additional  details. 

Host  memory  size:  37  Mbytes 

Communication  Link:  Ethernet 


Bus  System:  VME  BUS 

Floating  Point  Co-Processor:  MC68882 

For  technical  information  about  this  Ada  implementation,  contact: 

Tim  Magness 

SD-Scicon  UK  Limited 

Pembroke  House 

Pembroke  Broadway 

Camberley 

Surrey 

GU15  3XD 

For  sales  information  about  this  Ada  implementation,  contact: 

Colin  Foster 

SD-Scicon  UK  Limited 

Pembroke  House 

Pembroke  Broadway 

Camberley 

Surrey 

GU15  3XD 

Testing  of  this  Ada  implementation  was  conducted  at  the  customer’s  site  by  a  validation  team  from 
the  AVF. 
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3.2  SUMMARY  OF  TEST  RESULTS 

An  Ada  Implementation  passes  a  given  ACVC  version  if  it  processes  each  test  of  the  customized  test 
suite  in  accordance  with  the  Ada  Programming  Language  Standard,  whether  the  test  is  applicable  or 
inapplicable;  otherwise,  the  Ada  Implementation  fails  the  ACVC  [Pro90]. 

For  all  processed  tests  (inapplicable  and  applicable),  a  result  was  obtained  that  conforms  to  the  Ada 
Programming  Language  Standard. 

The  list  of  items  below  gives  the  number  of  ACVC  tests  in  various  categories.  All  tests  were 
processed,  except  those  that  were  withdrawn  because  of  test  errors  (item  b;  see  section  2.1),  those 
that  require  a  floating-point  precision  that  exceeds  the  implementation’s  maximum  precision  (item 
e;  see  section  2.2),  and  those  that  depend  on  the  support  of  a  file  system  -  if  none  is  supported  (item 

d).  All  tests  passed,  except  those  that  are  listed  in  sections  2.1  and  2.2  (counted  in  items  b  and  f, 
below). 


a)  Total  Number  of  Applicable  Tests  3839 

b)  Total  Number  of  Withdrawn  Tests  95 

c)  Processed  Inapplicable  Tests  236 

d)  Non-Processed  I/O  Tests  0 

e)  Non-Processed  Floating-Point  Precision  Tests  0 

f)  Total  Number  of  Inapplicable  Tests  236  (c-t-d-l-e) 

g)  Total  Number  of  Tests  for  ACVC  1.11  4170  (a-t-b-l-f) 


3.3  TEST  EXECUTION 

A  magnetic  tape  containing  the  customized  test  suite  (see  section  1.3)  was  taken  on-site  by  the 
validation  team  for  processing.  The  contents  of  the  magnetic  tape  were  loaded  onto  a  VAX  8600  and 
were  transferred  via  DECnet  to  the  host  computer. 

After  the  test  files  were  loaded  onto  the  host  computer,  the  full  set  of  tests  was  processed  by  the  Ada 
implementation. 

The  tests  were  compiler  and  linked  on  the  host  computer  system,  as  appropriate.  The  executable 
images  were  transferred  to  the  target  computer  system  by  the  communications  link  described  above, 
and  run.  The  results  were  captured  on  the  host  computer  system. 
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Testing  was  performed  using  command  scripts  provided  by  the  customer  and  reviewed  by  the 
validation  team.  See  Appendix  B  for  a  complete  listing  of  the  processing  options  for  this 
implementation.  It  also  indicates  the  default  options.  The  options  invoked  explicitly  for  validation 
testing  during  this  test  were: 

/LIST  used  for  tests  for  which  compilation  listings  are  required 

/DEV=DAY_0  in-house  compiler  option  to  remove  extraneous  listing  information  (eg  dates 

and  headers). 

Test  output,  compiler  and  linker  listings,  and  job  logs  were  captured  on  magnetic  tape  and  archived 
at  the  AVF.  The  listings  examined  on-site  by  the  validation  team  were  also  archived.  « 
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APPENDIX  A 

MACRO  PARAMETERS 

This  appendix  contains  the  macro  parameters  used  for  customizing  the  ACVC.  The  meaning  and 
purpose  of  these  parameters  are  explained  in  [UG89].  The  parameter  values  are  presented  in  two 
tables.  The  first  table  lists  the  values  that  are  defined  in  terms  of  the  maximum  input-line  length, 
which  is  the  value  for  $MAX_IN_LEN"also  listed  here.  These  values  are  expressed  here  as  Ada 
string  aggregates,  where  "V  represents  the  maximum  input-line  length. 

Macro  Parameter 

Macro  Value 

$MAX_IN_LEN 

255 

$BIG_ID1 

II 

V 

< 

II 

V 

$BIG_[D2 

(1..V.1  =>  ’A’,  V  =  >  ’2’) 

$BIG_ID3 

(1..V/2  =>  ’A’)  &  ’3’  &  (1..V-1-V/2  =>  ’A’) 

$BIG_ID4 

(1..V/2  =>  ’A’)  &  ’4’  &  (1..V-1-V/2  =>  ’A’) 

$BIG_INT_Lrr 

(1..V.3  => ’O’)  &  "298" 

$BIG_REAL_LIT 

(1..V-5  =>  ’O’)  &  "690.0" 

$BIG_STRING1 

’"’  &  (1..V/2  =>  ’A’)  &  ’"’ 

$BIG_STRING2 

’"’  &  (1..V-1-V/2  =>  ’A’)  &  ’1’  &  ’"’ 

SBLANKS 

(1..V-20  =>  ”) 

$MAX  LEN  INT  BASED  LITERAL 

"2:"  &  (1..V-5  => ’O’)  &  "11:" 

SMAX  LEN  REAL  BASED  LITERAL 

"16:"  &  (1..V-7  =>  ’O’)  &  "F.E:" 

$MAX_STRING_LITERAL 

’"’  &  (1..V-2  =>  ’A’)  &  ’"’ 

The  following  table  lists  ail  of  the  other  macro  parameters  and  their  respective  values. 
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Macro  Parameter 

Macro  Value 

$ACC_SIZE 

32 

$ALIGNMENT 

1 

$COUNT_LAST 

2147483647 

$DEFAULT_MEM_SIZE 

2147483647 

$DEFAlJLT_STOR_UNIT 

8 

$DEFAULT_SYS_NAME 

MC68020 

$DELTA_DOC 

2#1.0#E-31 

$ENTRY_ADDRESS 

SYSTEM.TO^ADDRESS  (16#68#) 

$ENTRY_ADDRESS1 

SYSTEM.TO_ADDRESS  (16#6C#) 

$ENTRY_ADDRESS2 

SYSTEM.TO_ADDRESS  (16#70#) 

$FIELD_LAST 

255 

SnLE.TERMINATOR 

ASCII.CR&ASCII.FF&ASCII.SUB 

$FIXED_NAME 

NO_SUCH_TYPE 

$FLOAT_NAME 

LONG_LONG_FLOAT 

$FORM_STRING 

Wl» 

$FORM_STRING2 

"CANNOT_RESTRICT_FILE_CAPACITY" 

$GREATER_THAN_DURATION 

131072.0 

SGREATER  THAN  DURATION  BASE  LAST 

131073.0 

SGREATER  THAN  FLOAT  BASE  LAST 

3.40283E+38 

SGREATER  THAN  FLOAT  SAFE  LARGE 

4.25354E+37 

SGREATER  THAN  SHORT  FLOAT  SAFE  LARGE 

"NO_SUCH_TYPE" 
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$HIGH_PRIORITY 

15 

$ILLEGAL_EXTERNAL_nLE  NAMEl 

ILLEGAL;FILE_NAME  1 

$ILLEGAL_EXTERNAL_FILE  NAME2 

ILLEGAL:  nLE_NAME  2 

- 

$INAPPROPRIATE_LINE_LENGTH 

-1 

$INAPPROPRIATE_PAGE_LENGTH 

-1 

$INCLUDE_PRAGMA1 

PRAGMA  INCLUDE  ("A28006D1.TST") 

‘ 

$INCLUDE_PRAGMA2 

PRAGMA  INCLUDE  ("B28006Dl.TS'r) 

$INTEGER_FIRST 

-2147483648 

$INTEGER_LAST 

2147483647 

$INTEGER_LAST_PLUS_1 

2147483648 

$INTERFACE_LANGUAGE 

ASSEMBLER 

$LESS_THAN_DURATION 

-131072.0 

$LESS_THAN_DURATION  BASE  RRST 

-131073.0 

$LINE_TERMlNATOR 

ASCII.CR 

$LOW_PRIORITY 

0 

$MACHINE_CODE_STATEMENT 

OPERANDLESS_INST’(OPCODE=  >NOP); 

$MACHlNE_CODE_TYPE 

OPERANDLESS_INST 

$MANTISSA_DOC 

31 

$MAX_DIGITS 

18 

$MAX_INT 

2147483647 

$MAX_INT_PLUS_1 

2147483648 

SMIN_INT 

-2147483648 
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$NAME 

$NAME_LIST 

$NAME_SPECIFICATIONl 

$NAME_SPECrFICATION2 

$NAME_SPECIFICATION3 

$NEG_BASED_INT 

$NEW_MEM_SIZE 

$NEW_STOR_UNIT 

$NEW_SYS_NAME 

$PAGE_TERMINATOR 

$RECORD_DEFINmON 

$RECORD_NAME 

$TASK_SIZE 

$TASK_STORAGE_SIZE 

STICK 

$VARIABLE_ADDRESS 

$VARIABLE_ADDRESS1 

SVARIABLE_ADDRESS2 

$YOUR_PRAGMA 
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SHORT_SHORT_INTEGER 

MC68020 

X2120A 

X2120B 

X3119A 

16#FFFF_FFFF# 

123456 

8 

MC68020 

ASCII.CR&ASCIIFF 

RECORD  OPCODE:OPERANDLESSOP;END  RECORD; 

OPERANDLESSJNST 

32 

2048 

162.5E-6 

SYSTEM.TO_ADDRESS  (16#40C#) 
SYSTEM.TO_ADDRESS  (16#408#) 
SYSTEM.TO_ADDRESS  (16#404#) 

EXPORT_OBJECT 
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APPENDIX  B 

COMPILATION  SYSTEM  OPTIONS 


The  compiler  options  of  this  Ada  implementation,  as  described  in  this  Appendix,  are  provided  by  the 
customer.  Unless  specifically  noted  otherwise,  references  in  this  appendix  are  to  compiler 
documentation  and  not  to  this  report. 
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XDADA 


XDADA 

Invokes  the  XD  Ada  compiler  to  co 

impile  one  or  more  source  files. 

Format 

XDADA  file-specf,...] 

Command  Qualifiers 

Defaults 

/LIBRARY  =  directory-spec 

/LIBRARY  .XDADASLIB 

Positional  Qualifiers 

Defaults 

/(NOJANALYSIS.DATAl  =  file-spec) 

/NOANALYSIS.DATA 

/(NOICHECK 

See  text. 

/(NOICOPY.SOURCE 

/COPY.SOURCE 

/(N01DEBUG(=  (option).. ..Dl 

/DEBUG  =  ALL 

/(NOIDIAGNOSTICS)  =  file-spec) 

/NODIAGNOSTICS 

/(NO)ERROR_LIMIT(  =  n) 

/ERROR_LIMIT  =  30 

/(NO)UST(»  file-spec) 

/NOLIST 

/(NO)LOAD(  =  option) 

/LOAD  -  REPLACE 

/(NO)MACHINE_CODE(  =  option) 

/NOMACHINE.CODE 

/(NO)NOTE_SOURCE 

/NOTE.SOURCE 

/(NO)OPTIMIZE(  =  option) 

See  text. 

/1N0)PREDEF1NED_UNIT 

/NOPREDEFINED.UNIT 

/(NO)SHOW(  =  option) 

/SHOW  =  PORTABILITY 

/(NOISYNTAX.ONLY 

/NOSYNTAX.ONLY 

/(NO)  WARNINGS) » (option(...,))) 

See  text. 

Prompt 

.File: 

Command  Parameters 


files  lec 

Spe*;i*ies  one  or  more  XD  Ada  source  files  to  be  compiled.  If  you  do 
not  specify  a  file  type,  the  compiler  uses  the  default  file  type  of  ADA. 
No  wildcard  characters  are  allowed  in  the  file  specifications. 


B-2  XDADA  Command  Definition 


XDADA 


If  you  specify  several  source  files  as  arguments  to  the  XDADA  com¬ 
mand,  you  must  separate  adjacent  file  specifications  with  a  comma  ( , } 
If  you  specify  more  than  one  input  file,  you  must  separate  adjacent  file 
specifications  with  a  comma  (, ).  You  cannot  use  a  plus  sign  (  -t-  )  to 
separate  file  specifications. 


Description 

The  XDADA  command  is  one  of  four  commands  used  to  compile  com¬ 
pilation  units.  The  other  three  are  the  XDACS  COMPILE,  RECOMPILE 
and  LOAD  commands. 

The  XDADA  command  can  be  used  at  any  time  to  compile  one  or 
more  source  files  (.ADA).  Source  files  are  compiled  in  the  order  they 
appear  on  the  command  line.  If  a  source  file  contains  more  than  one 
compilation  unit,  they  are  compiled  in  the  order  they  appear  in  the 
source  file. 

The  XDADA  command  compiles  units  in  the  context  of  the  current 
program  library.  Whenever  a  compilation  unit  is  compiled  without 
error,  the  current  program  library  is  updated  with  the  object  module 
and  other  products  of  the  compilation. 


Command  Qualifiers 

/LIBRARY = directory-spec 

Specifies  the  program  library  that  is  to  be  the  current  program  library 
for  the  duration  of  the  compilation.  The  directory  specified  must  be  an 
already  existing  XD  Ada  program  library.  No  wildcard  characters  are 
allowed  in  the  directory  specificahon. 

By  default,  the  current  program  library  is  the  program  library  last 
specified  in  an  XDACS  SET  LIBRARY  command.  The  logical  name 
XDADASLIB  is  assigned  to  the  program  library  specified  in  an  XDCAS 
SET  LIBRARY  command. 


Positional  Qualifiers 

I  ANALYSIS  _DATA[  =  file-spec] 

/NOANALYSIS_DATA  (D) 

Controls  whether  a  data  analysis  file  containing  source  code  cross- 
reference  and  static  analysis  information  is  created.  The  data  analysis 
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XDADA 


file  is  supported  only  for  use  with  DIGITAL  layered  products,  such  as 
the  VAX  Source  Code  Analyzer. 

One  data  analysis  file  is  created  for  each  source  file  compiled.  The 
default  directory  for  data  analysis  files  is  the  current  default  directory. 
The  default  file  name  is  the  name  of  the  source  file  being  compiled. 
The  default  file  type  is  ANA.  No  wildcard  characters  are  allowed  in  the 
file  specification. 

By  default,  no  data  analysis  file  is  created. 

ICHECK 

/NOCHECK 

Controls  whether  all  run-time  checks  are  suppressed.  The  /NOCHECK 
qualifier  is  equivalent  to  having  all  possible  SUPPRESS  pragmas  in  the 
source  code. 

Explicit  use  of  the  /CHECK  qualifier  overrides  any  occurrences  of  the 
pragmas  SUPPRESS  and  SUPPRESS_ALL  in  the  source  code,  without 
the  need  to  edit  the  source  code. 

By  default,  run-time  checks  are  suppressed  only  in  cases  where  a 
pragma  SUPPRESS  or  SUPPRESS_ALL  appears  in  the  source. 

See  the  Reference  Manual  for  the  Ada  Programming  Language  for  more 
information  on  the  pragmas  SUPPRESS  and  SUPPRESS_ALL. 

/COPY_SOURCE  (D) 

inoc6py_source 

Controls  whether  a  copied  source  file  (.ADC)  is  created  in  the  current 
program  library  when  a  compilation  unit  is  compiled  without  error.  The 
RECOMPILE  command  (and  thus  the  COMPILE  command)  requires 
that  a  copied  source  file  exist  in  the  current  program  library  for  any  unit 
that  is  to  be  recompiled. 

By  default,  a  copied  source  file  is  created  in  the  current  program  library 
when  a  unit  is  compiled  without  error. 

IDEBUG[=:(optlonl....])J  (D) 

INODEBUG 

Controls  which  compiler  debugging  options  are  provided.  You  can 
debug  XD  Ada  programs  with  the  XD  Ada  Debugger.  You  can  request 
the  following  options: 
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ALL 

NONE 

[NOISYMBOLS 

INOjTRACEBACK 


Provides  both  SYMBOLS  and  TRACEBACK, 

Provides  neither  SYMBOLS  nor  TRACEBACK. 

Controls  whether  debugger  symbol  records  are  in¬ 
cluded  in  the  object  Hie. 

Controls  whether  traceback  information  (a  subset  of 
the  debugger  symbol  information)  is  included  in  the 
object  Hie. 


By  default,  both  debugger  symbol  records  and  traceback  information  are 
included  in  the  object  file  (/DEBUG- ALL,  or  equivalently;  /DEBUG). 

/DIAGNOSTICS[  =  file-spec] 

/NODIAGNOSTICS  (D) 

Controls  whether  a  diagnostics  file  containing  compiler  messages  and 
diagnostic  information  is  created.  The  diagnostics  file  is  supported  only 
for  use  with  DIGITAL  layered  products,  such  as  the  VAX  L'.nguage- 
Sensitive  Editor. 

One  diagnostics  file  is  created  for  each  source  file  compiled.  The 
default  directory  for  diagnostics  files  is  the  current  default  directory. 

The  default  file  name  is  the  name  of  the  source  file  being  compiled. 
The  default  file  type  is  DIA.  No  wildcard  characters  are  allowed  in  the 
file  specification. 

By  default,  no  diagnostics  file  is  created. 

IERROR_UMIT[  =  nJ 
INOERROR_UMIT 

Controls  whether  execution  of  the  XDADA  command  for  a  given 
compilation  unit  is  terminated  upon  the  occurrence  of  the  nth  E-level 
error  within  that  unit. 

Error  counts  are  not  accumulated  across  a  sequence  of  compilation 
units.  If  the  /ERROR_LIMIT-n  option  is  specified,  each  compilation 
unit  may  have  up  to  n-1  errors  without  terminating  the  compilation. 
’.'Vhen  the  error  limit  is  reached  within  a  compilation  unit,  compilation  of 
that  unit  is  terminated,  but  compilation  of  subsequent  units  continues. 

The  /ERROR_LlMIT  -0  option  is  equivalent  to  ERROR.LIMIT  -  1. 

By  default,  execution  of  the  XDADA  command  is  terminated  for  a  given 
compilation  unit  upon  the  occurrence  of  the  30th  E-level  error  wnthin 
that  unit  (equivalent  to  /ERROR.LIMIT  -30). 
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I  UST[  =  file-spec] 

INOLIST  (D) 

Controls  whether  a  listing  file  is  created.  One  listing  file  is  created 
for  each  source  file  compiled.  The  default  directory  for  lishng  files  is 
the  current  default  directory.  The  default  file  name  is  the  name  of  the 
source  file  being  compiled.  The  default  file  type  is  .LIS.  No  wildcard 
characters  are  allowed  in  the  file  specification. 

By  default,  the  XDADA  command  does  not  create  a  listing  file. 

I  LOAD]  =  option]  (D) 

INOLOAD 

Controls  whether  the  current  program  library  is  updated  with  the 
successfully  processed  units  contained  in  the  specified  source  files. 
Depending  on  other  qualifiers  specified  (or  not  specified)  with  the 
XDADA  command,  processing  can  involve  full  compilation,  syntax 
checking  only,  and  so  on.  The  /NOLOAD  qualifier  causes  the  units 
in  the  specified  source  files  to  be  processed,  but  prevents  the  current 
program  library  from  being  updated. 

You  can  specify  the  following  option; 

(NOIREPLACE  Controls  whether  a  unit  added  to  the  current 

program  library  replaces  an  existing  unit  with  the 
same  name.  If  you  specify  the  NOREPLACE  option, 
the  unit  is  adde^  '  .e  current  program  library  only 
if  no  existin'?  unit  has  the  same  name,  except  if  the 
new  unit  is  the  corresponding  body  of  an  existing 
speciHcation  or  vice  versa. 

By  default,  the  c  irrent  program  library  is  updated  with  the  success¬ 
fully  processed  units,  and  a  unit  added  to  the  current  program  library 
replaces  an  existing  unit  with  the  same  name. 

IMACHINE_CODE[  =  Option] 

INOMACHINE_CODE  (D) 

Controls  whether  generated  machine  code  (approximating  assembly 
language  notation)  is  included  in  the  listing  file. 

You  can  specify  one  of  the  following  options; 
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SYMBOLIC. NONE  Provides  machine  code  listing  with  no  annotation. 

SYMBOLIC;NORMAL  Provides  machine  code  in  the  listing  hie:  where 

possible,  instructions  are  annotated  with  simple  Ada 
names. 

SYMBOlJC;MAXIMAL  Provides  machine  code  in  the  listing  Hie;  where 

possible,  instructions  are  annotated  with  Ada  names, 
in  expanded  form  if  necessary. 

The  /MACHINE  CODE  qualifier  without  options  is  equivalent  to 
/MACHINE.CODE  -  SYMBOLIC: NORM AL, 

/NOTE  SOURCE  (D) 

I  NONOTE  _SOURCE 

Controls  whether  the  file  specification  of  the  source  file  is  noted  in  the 
program  library  when  a  unit  is  compiled  without  error.  The  COMPILE 
command  uses  this  information  to  locate  revised  source  files. 

By  default,  the  file  specification  of  the  source  file  is  noted  in  the  pro¬ 
gram  library  when  a  unit  is  compiled  without  error, 

/OPTIMfZE[=(optlon[.  .  .  .  ]) 

/NOOPTIMIZE 

Controls  the  level  of  optimization  that  is  applied  in  producing  the 
compiled  code.  You  can  specify  one  of  the  following  primary  options: 

Provides  full  optimization  with  time  as  the  primary 
optimization  criterion.  Overrides  any  occurrences  of 
the  pragma  OPTIMIZE(SPACE)  in  the  source  code. 

Provides  full  optimization  with  space  as  the  primary 
optimization  criterion.  Overrides  any  occurrences  of 
the  pragma  OPTIMIZE(TIME)  in  the  source  code. 

Suggested  when  active  development  of  a  program 
is  in  progress.  Provides  some  optimization,  but 
development  considerations  and  ease  of  debugging 
take  preference  over  optimization.  This  option 
overrides  pragmas  that  establish  a  dependence  on  a 
subprogram  tthe  pragma  INLINE),  and  thus  reduces 
the  ne^  for  recompilations  when  such  bodies  are 
modified. 

none  Provides  no  optimization.  Suppresses  expansions  in 

line  of  subprograms,  including  those  speafied  by  the 
pragma  INLINE. 

The  /NOOPTIMIZE  qualifier  is  equivalent  to  /OPTIMIZE -NONE. 


TIME 

SPACE 

DEVELOPMENT 
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By  default,  the  -XDADA  command  applies  full  optimization  with  time 
as  the  primary  optimization  criterion  (like  /OPTIMIZE -TIME,  but 
observing  uses  of  the  pragma  OPTIMIZE). 

The  /OPTIMIZE  qualifier  also  has  a  set  of  secondary  options  that  you 
can  use  separately  or  together  with  the  primary  options  to  override  the 
default  behavior  for  inline  expansion  and  code  motion. 

The  INLINE  secondary  option  can  have  the  following  values; 

INUNEiNONE  Disables  subprogram  expansion  in  line.  This  option 

overrides  any  occurrences  of  the  pragma  INLINE 
in  the  source  code,  without  having  to  edit  the 
source  file.  It  also  disables  implicit  expansion  in 
line  of  subprograms.  (Implicit  expansion  in  line  means 
that  the  compiler  assumes  a  pragma  INLINE  for 
certain  subprograms  as  an  optimization.)  A  call  to  a 
subprogram  in  another  unit  is  not  expanded  in  line, 
regardless  of  the  /OPTIMIZE  options  in  effect  when 
that  unit  was  compiled. 

INUNEiNORMAL  Provides  normal  subprogram  expansion  in  line. 

Subprograms  to  which  an  explicit  pragma  INLINE 
applies  are  expanded  in  line  under  certain  condi¬ 
tions.  In  addition,  some  subprograms  are  implicitly 
expanded  in  line.  The  compiler  assumes  a  pragma 
INLINE  for  calls  to  some  small  local  subprograms 
(subprograms  that  are  declared  in  the  same  unit  as 
the  unit  in  which  the  call  occurs). 

INLINE;SUBPROGRAMS  Provides  maximal  subprogram  expansion  in  line.  In 

addition  to  the  normal  subprogram  expansion  in 
line  that  occurs  when  INUNEiNORMAL  is  specified, 
this  option  results  in  implicit  expansion  in  line  of 
some  small  subprograms  declared  in  other  units. 

The  compiler  assumes  a  pragma  INLINE  for  any 
subprogram  if  it  improves  execution  speed  and 
reduces  code  size.  This  option  may  establish  a 
dependence  on  the  body  of  another  unit,  as  would  be 
the  case  if  a  pragma  INLINE  were  specified  explicitly 
in  the  source  code. 
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INUNEiMAXIMAL  Provides  maximal  subprogram  expansion  in  line. 

Maximal  subprogram  expansion  in  line  occurs  as  for 
INUNEiSUBPROGRAMS. 

INUNEiGENERICS  Provides  normal  subprogram  inline  expansion  and 

maximal  generic  inline  expansion.  With  this  option, 
subprogram  inline  expansion  occurs  in  the  same 
manner  as  for  INLINE; NORMAL.  The  compiler 
assumes  a  pragma  INUNE.GENERIC  for  every 
instantiation  in  the  unit  being  compiled  unless 
a  generic  body  is  not  available.  This  option  may 
establish  a  dependence  on  the  body  of  another  unit, 
as  would  be  the  case  if  a  pragma  INUNE.GENERIC 
were  specified  explicitly  in  the  source  code. 

The  MOTION  secondary  option  can  have  the  following  values: 

MOTIONrNONE  Disables  code  motion  optimizations. 

MOTION;LOOPS  Permits  code  motion  optimization  of  loops.  Where 

the  compiler  detects  that  a  loop  body  contains 
invariant  processing,  it  may  generate  code  in  which 
this  processing  is  performed  before  entry  to  the  loop 
instead  of  within  the  loop. 

MOTION '.MAXIMAL  Permits  all  code  motion  optimizations.  In  addition 

to  the  optimization  of  loops  that  occurs  when 
MOTION'.LOOPS  is  specified,  this  option  permits 
analogous  optinuzation  of  if  and  case  statements: 
where  the  compiler  detects  that  the  branches  of  an  if 
or  case  statement  contain  common  processing,  it  may 
generate  code  in  which  this  processing  is  performed 
before  evaluation  of  the  corresponding  condition  or 
case  expression  instead  of  within  the  branches. 

By  default,  the  /OPTIMIZE  qualifier  primary  options  have  the  following 
secondary-option  values; 

/OPTIMIZE  -  TIME  -  (INUNE;  NORMAL,  MOTION :  LOOPS) 

/OPTIMIZE -SPACE  -(INUNE:  NORMAL.  MOTION:  MAXIMAL) 

/OPTIMIZE- DEVELOPMENT  =(lNUNE:NONE,MOTION;NONE) 
/OPTIMIZE-NONE  -(INUNE:NONE.MOTION;NONE) 

IPREOEFINEOJJNIT 
INOPREDEFlNED_UNIT  (D) 

Controls  the  compilation  of  package  $RUN_TIME_SYSTEM,  pack¬ 
age  STASKING_SYSTEM,  and  package  MACHlNE_CODE.  You  must 
specify  this  qualifier  in  order  to  be  able  to  compile  these  packages. 
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The  qualifier  is  not  required  for  the  compilation  of  anv  other  source 
files.  See  the  XD  Aiia  MC6S020  Run-Time  Reference  Manual  for  more 
informafion. 

By  default,  /PREDEFINED_UNIT  is  omitted. 

/SHOW[  =  option]  (D) 

INOSHOW 

Controls  the  listing  file  options  included  when  a  listing  file  is  provided. 
You  can  specify  one  of  the  following  options: 

Provides  all  listing  file  options. 

Controls  whether  a  program  portability  summary 
is  included  in  the  listing  file.  By  default,  the 
XDADA  command  provides  a  portability  sum¬ 
mary  (/SHOW* PORTABILITY).  See  Appendix  E 
for  details  of  what  can  be  included  in  a  porta¬ 
bility  summary.  See  Chapter  5  of  Version  2.0  of 
Developing  Ada  Programs  on  VMS  Systems  for  more 
information  on  program  portability. 

NONE  Provides  none  of  the  listing  file  options  (same  as 

/NOSHOW). 

By  default,  the  XDADA  command  provides  a  portability  summary 
(/SHOW  -  PORTABIUTY). 

/SYNTAX  ONLY 
INOSYNTAX^ONLY  (D) 

Controls  whether  the  source  file  is  to  be  checked  only  for  correct  syntax. 
If  you  specify  the  /SYNTAX_ONLY  qualifier,  other  compiler  checks  are 
not  performed  (for  example,  semantic  analysis,  type  checking,  and  so 
on). 

By  default,  the  compiler  performs  all  checks. 

/WARNINGS[=(message-optlon[, ...])] 
iNOWARNINGS 

Controls  which  categories  of  informational  (I-level)  and  warning  (W- 
level)  messages  are  displayed  and  where  those  messages  are  displayed. 
You  can  specify  any  combination  of  the  following  message  options: 

WARNINGS:  {destination\....]) 

NOWARNINGS 

WEAK.WARNINGS:  (dcsfuinfion[, ...1) 


ALL 

[NOlPORTABIUTY 
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NOW'EAK.VVARNINGS 

SUPPLEMENTAL:  . .  1) 

NOSUPPLEMENTAL 

COMPILATION  NOTES;  (destinationl. . . .]) 
NOCOMPILATION.NOTES 

STATUS:  {destinatton[,...]) 

NOSTATUS 


The  possible  values  of  destination  are  ALL,  NONE,  or  any  combination 
of  TERMINAL  (terminal  device),  LISTING  (listing  file),  DIAGNOSTICS 
(diagnostics  file).  The  message  categories  are  summarized  as  follows: 


WARNINGS 

WEAK.WARNINCS 


SUPPLEMENTAL 

C0MP1L\T10N.N0TES 


STATUS 


W-level:  Indicates  a  definite  problem  in  a  legal 
program,  for  example,  an  unknown  pragma. 

l-level:  Indicates  a  potential  problem  in 
a  legal  program;  for  example,  a  possible 
CONSTRAlNT_ERROR  at  run  time.  These 
are  the  only  kind  of  I-level  messages  that  are 
counted  in  the  summary  statistics  at  the  end  of 
a  compilation. 

I-level;  Additional  information  associated  with 
preceding  E-level  or  W-level  diagnostics. 

I-level:  Information  about  how  the  compiler 
translated  a  program,  such  as  record  layout, 
parameter-passing  mechanisms,  or  decisions 
made  for  the  pragmas  INLINE,  INTERFACE,  or 
the  import-subprogram  pragmas. 

I-Ievei;  End  of  compilation  statistics  and  other 
messages. 


The  defaults  are  as  follows. 

/  WARfI  I.'JGS-  (  WARN :  At!.,  WEAK :  ALL,  SUPP :  ALL,  CCMP :  tIONE ,  STAT :  LI  ST  I 

Note  that  abbreviations  are  valid. 

If  you  specify  only  some  of  the  message  categories  with  the 
/WARNINGS  qualifier,  the  default  values  for  other  categories  are  used. 
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Examples 

1  3  XDACA  MODE:L_;‘;TERFAC£_,MCOEI,_;riTERFACE, 

The  XDADA  command  compiles  the  compilation  units  con¬ 
tained  in  the  three  files  MODEL_INTERFACE_.ADA,  MODEL, 
INTERFACE. ADA,  and  CONTROL_LOOP.ADA,  in  the  order  given. 

2.  s  xdada/list/show-all  screen, io_, screen, :o 

The  XDADA  command  compiles  the  compilation  units  contained 
in  the  two  files  SCREEN,IO,.ADA  and  SCREEN,IO.ADA,  in  the 
order  given.  The  /LIST  qualifier  creates  the  listing  files  SCREEN, 
lO,.LIS  and  SCREEN,IO.LIS  in  the  current  default  directory.  The 
/SHOW  -  ALL  qualifier  causes  all  listing  file  options  to  be  provided 
in  the  listing  files. 
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LINKER  OPTIONS 

The  linker  options  of  this  Ada  implementation,  as  described  in  this  Appendix,  are  provided  by  the 
customer.  Unless  specifically  noted  otherwise,  references  in  this  appendix  are  to  linker  documentation 
and  not  to  this  report. 


Validitian  SuMi-y  Report 


SO-Scicon  UK  Liaited 
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LINK 


Creates  an  executable  image  file  for  the  specified  units. 


Format  LINK  unit-name  [file-spec[,...JJ 

LINK/NO  MAIN  unit-name[,...J  file-spec[,...] 


Command  Qualifiers 

Defaults 

/AFTER  *  time 

/AFTER  =.  TODAY 

/BATCH^LOG  =  file-spec 

See  text. 

/BRIEF 

See  text. 

/COMMAND!  >  file-spec) 

See  text. 

/(NOjOEBUG 

/NODEBUG 

/ELABORATION  » file-spec 

See  text. 

/FULL 

See  text. 

/(NOllMAGEl- file-spec) 

/IMAGE 

/{NOjKEEP 

/KEEP 

/(NO]LOG 

/NOLOG 

/(NO)MAIN 

/MAIN 

/1N0)MAPI  =  file-spec) 

/NOMAP 

/NAME  s  job-name 

See  text. 

/(NO)NOTIFY 

/NOTIFY 

/OUTPUT  =  file-spec 

/OUTPUT  =  SYSSOUTPUT 

/(NO)PRINTER( »  queue-name) 

/NOPRINTER 

/QUEUE  »  queue-name 

/QUEUE  »SYS$BATCH 

/1N0)SELECTIVE 

/SELECTIVE 

/SUBMIT 

/WAIT 

/WAIT 

/WAIT 

Parameter  Qualifiers 

Defaults 

/LIBRARY 

See  text. 

/MAPPING 

See  text. 

/TARGET 

See  text. 
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Prompts 


Unit; 

.File; 


Command  Parameters 

unit-name 

By  default  (or  if  you  specify  the  /MAIN  qualifier): 

•  You  can  specify  only  one  unit,  the  source  code  of  which  must  be 
written  in  XD  Ada. 

•  The  parameter  unit-name  specifies  the  XD  Ada  main  program,  which 
must  be  a  procedure  or  function  with  no  parameters.  If  the  main 
program  is  a  function,  it  must  return  a  value  of  a  discrete  type;  the 
function  value  is  used  as  the  VMS  image  exit  value. 

If  you  specify  the  /NOMAIN  qualifier: 

•  You  can  specify  one  or  more  foreign  units  that  are  to  be  included 
in  the  executable  image.  The  unit  names  may  include  percent  signs 
(%)  and  asterisks  (*)  as  wildcard  characters.  (See  the  VMS  DCL 
Concepts  Manual  for  detailed  information  on  wildcard  characters.) 

•  TTie  '  adge  transfer  address  comes  from  one  of  the  foreign  files 
jf  cified. 

/lie-spec 

Specifies  a  list  of  object  files,  object  libraries,  mapping  definition  files, 
and  target  definition  files,  that  are  to  be  used  in  linking  the  program. 
The  default  directory  is  the  current  default  directory.  The  default  file 
type  is  .XOB,  unless  the  /LIBRARY,  /MAPPING,  or  /TARGET  qualifier  is 
used.  No  wildcard  characters  are  allowed  in  a  file  specification. 

If  the  file  is  an  object  library,  you  must  use  the  /LIBRARY  qualifier.  The 
default  file  type  is  XLB 

If  the  file  is  a  mapping  definition  file,  you  must  use  the  /MAPPING 
qualifier.  The  default  file  type  is  MPD 

If  the  file  is  a  target  definition  file  you  must  use  the  /TARGET  qualifier. 
The  default  file  type  is  TGD. 

If  you  specify  the  /NOMAIN  qualifier,  the  image  transfer  address  comes 
from  one  of  the  files  (not  units)  specified. 
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Description 

The  LINK  command  performs  the  following  steps; 

1.  Runs  the  prebuild  phase  to  generate  an  elaboration  list. 

2.  Checks  if  a  pragma  LINK_OPnON  is  specified  for  the  main  pro¬ 
gram,  and  if  specified,  verifies  that  the  designated  iirdc  option  name 
is  available  m  the  current  program  library.  If  available,  the  copied 
link  option  files  in  the  library  corresponding  to  the  link  option  are 
used,  unless  overridden  by  the  /TARGET  or  /MAPPING  qualifiers. 

Note  that,  unlike  the  CHECK  command,  the  pragma  LINK_ 
OPTION  association  for  units  other  than  the  main  program  unit 
is  not  checked. 

If  no  target  liiJc  option  is  given  for  the  main  program  unit  or  the 
designated  target  link  option  is  not  found  in  the  library,  and  the 
logical  name  XDADASTARGET_DEF  is  not  defined,  and  a  /TARGET 
qualifier  is  not  specified  on  the  LINK  command  line,  an  error  is 
issued.  If  no  mapping  link  option  is  given  for  the  main  program  unit 
or  the  designated  mapping  link  option  is  not  found  in  the  library, 
and  the  logical  name  XDADA$MAPPING_DEF  is  not  defined,  and  a 
/MAPPING  qualifier  is  not  specified  on  the  XDACS  LINK  command 
line,  the  default  mapping  in  the  target  definition  file  is  used. 

3.  If  LINK/NOMAIN  is  not  specified,  checks  that  only  one  unit  is 
specified  and  that  it  is  an  XD  Ada  main  program. 

4.  Forms  the  closure  of  the  main  program  (LINK/MAIN)  or  of  the 
specified  units  (LINK/NOMAIN)  and  verifies  that  all  units  in  the 
closure  are  present,  current  and  complete.  If  XDACS  detects  an 
error,  the  operation  is  terminated  at  the  end  of  the  prebuild  phase. 

5.  Creates  a  DCL  command  file  for  the  builder.  The  command  file  is 
deleted  after  the  LINK  operation  is  completed  or  terminated,  unless 
LINK/COMMAND  is  specified.  If  UNK/COMMAND  is  specified, 
the  command  file  is  retained  for  future  use,  and  the  build  phase  is 
not  carried  out. 

6.  Unless  the  /COMMAND  qualifier  is  specified,  performs  the  build 
phase  as  follows: 

a.  By  default  (LINK/WAIT),  the  command  file  generated  in  step 
5  is  executed  in  a  subprocess.  You  must  wait  for  the  build 
operation  to  terminate  before  issuing  another  command.  Note 
that  when  you  specify  the  /WAIT  qualifier  (the  default),  process 
logical  names  are  propagated  to  the  subprocess  generated  to 
execute  the  command  file. 
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b.  If  you  specify  the  /SUBMIT  qualifier,  the  builder  command  file 
is  submitted  as  a  batch  job. 

7.  If  the  /DEBUG  qualifier  is  included  in  the  command  line  the  debug 
symbol  table  information  is  placed  in  the  .XXE  file. 

8.  Creates  a  loadable  output  file  with  a  default  file  type  of  XXE. 

XDACS  output  originating  before  the  builder  is  invoked  is  reported 
to  your  terminal  by  default,  or  to  a  file  specified  with  the  /OUTPUT 
qualifier.  Diagnostics  are  reported  to  your  terminal,  by  default,  or  to 
a  log  file  if  the  LINK  command  is  executed  in  batch  mode  (XDACS 
UNK/SUBMIT). 

See  Developing  XD  Ada  Programs  on  VMS  Systems  for  the  MC68020  and  the 
XD  Ada  Version  1.2  New  Features  Manual  for  more  information  on  the  XD 
Ada  target-specific  builder  commands. 


Command  Qualifiers 

I  AFTER  s  time 

Requests  that  the  batch  job  be  held  until  after  a  specific  time,  when 
the  LINK  command  is  executed  in  batch  mode  (LINK/SUBMIT).  If  the 
specified  time  has  already  passed,  the  job  is  queued  for  immediate 
processing. 

You  can  specify  either  an  absolute  time  or  a  combination  of  absolute 
and  delta  time.  See  the  VMS  DCL  Concepts  Manual  (or  type  HELP 
Specify  Date-Time  at  the  DCL  prompt)  for  complete  information  on 
specif^ng  time  values. 

IBATCH_LOG  =  file-spec 

Provides  a  file  specification  for  the  batch  log  file  when  the  LINK  com¬ 
mand  is  executed  in  batch  mode  (LINK/SUBMIT). 

If  you  do  not  give  a  directory  specification  with  the  file-spec  option,  the 
batch  log  file  is  created  by  default  in  the  current  default  directory.  If 
you  do  not  give  a  file  specification,  the  default  file  name  is  the  job  name 
specified  with  the  /NAME -job-name  qualifier.  If  no  job  name  has  been 
specified,  the  program  library  manager  creates  a  file  name  comprising 
up  to  the  first  39  characters  of  the  first  unit  name  specified.  If  you 
specified  LINK/NOMAIN  and  no  job  name  and  there  is  a  unldcard 
character  in  the  first  unit  specified,  the  program  library  manager  uses 
the  default  file  name  XDACS_LINK.  The  default  file  type  is  LOG. 
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/BRIEF 

Directs  the  builder  to  produce  a  brief  image  map  file.  The  /BRIEF 
qualifier  is  valid  only  if  you  also  specify  the  /MAP  qualifier  with  the 
LINK  command.  The  /BRIEF  qualifier  is  incompatible  with  the  /FULL 
qualifier. 

A  brief  image  map  file  contains  only  the  following  sections: 

•  Object  module  information 

•  Segment  mapping  information 

•  Link  run  statistics 

See  also  the  description  of  the  /FULL  qualifier. 

ICOMMANDl  =  file-spec] 

Controls  whether  the  builder  is  invoked  as  a  result  of  the  LINK  com¬ 
mand,  and  determines  whether  the  command  file  generated  to  invoke 
the  builder  is  saved.  If  you  specify  the  /COMMAND  qualifier,  XDACS 
does  not  invoke  the  builder,  and  the  generated  command  file  is  saved 
for  you  to  invoke  or  submit  as  a  batch  job. 

The  file-spec  option  allows  you  to  enter  a  file  specification  for  the  gen¬ 
erated  command  file.  The  default  directory  for  the  command  file  is  the 
current  default  directory.  By  default,  XDACS  provides  a  file  name  com¬ 
prising  up  to  the  first  39  characters  of  the  first  unit  name  specified.  If 
you  specified  LINK/NOMAIN  and  you  used  a  wildcard  character  in  the 
first  unit  name  specified,  the  program  library  manager  uses  the  default 
file  name  XDACS_LINK.  The  default  file  type  is  .COM.  No  wildcard 
characters  are  allowed  in  the  file  specification. 

By  default,  if  the  /COMMAND  qualifier  is  not  specified,  XDACS  deletes 
the  generated  command  file  when  the  LINK  command  completes 
normally  or  is  terminated. 

/DEBUG 
/NODEBUG  (D) 

Controls  whether  a  debugger  symbol  table  is  generated  in  the  loadable 
image  file. 

By  default,  no  debugger  symbol  table  is  created. 

/ELABORATION  =  file-spec 

Provides  a  file  specification  for  the  object  file  generated  by  the  LINK 
command.  The  file  is  retained  by  XDACS  only  when  the  /COMMAND 
qualifier  is  used:  that  is,  when  the  result  of  the  LINK  operation  is  to 
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produce  a  builder  command  tile  for  future  use,  rather  than  to  invoke  the 
builder  immediately 

The  generated  object  file  contains  the  code  that  directs  the  elaboration 
of  library  packages  in  the  closure  of  the  units  specified.  Unless  you  also 
specify  the  /NOMAIN  qualifier,  the  object  file  also  contains  the  image 
transfer  address. 

The  default  directory  for  the  generated  text  file  is  the  current  default 
directory.  The  default  file  type  is  .ELB.  No  wildcard  characters  are 
allowed  in  the  file  specification. 

By  default,  if  you  do  not  specify  the  /ELABORATION  qualifier,  XDACS 
provides  a  file  name  comprising  up  to  the  first  39  characters  of  the  first 
unit  name  specified. 

By  default,  if  you  do  not  specify  the  /COMMAND  qualifier,  XDACS 
deletes  the  generated  object  file  when  the  LINK  command  completes 
normally  or  is  terminated. 

/FULL 

Directs  the  builder  to  produce  a  full  image  map  file,  which  is  the  most 
complete  image  map.  The  /FULL  qualifier  is  valid  only  if  you  also 
specify  the  /MAP  qualifier  with  the  LINK  command.  Also,  the  /FULL 
qualifier  is  incompatible  with  the  /BRIEF  qualifier. 

A  full  image  map  file  contains  the  following  sections: 

•  Object  module  information 

•  Segment  mapping  information 

•  Symbol  address  information 

•  Exception  numbers 

•  Link  run  statistics 

/IMAGEl  =  file-spec]  (D) 

INOIMAGE 

Controls  whether  the  LINK  command  creates  a  loadable  image  file  and 
optionally  provides  a  file  specification  for  the  file.  The  default  file  type 
is  .XXE.  No  wildcard  characters  are  allowed  in  the  file  specification. 

By  default,  an  executable  image  file  is  created  with  a  file  name  compris¬ 
ing  up  to  the  first  39  characters  of  the  first  unit  name  specified. 
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/KEEP  (0) 

INOKEEP 

Controls  whether  the  batch  log  file  generated  is  deleted  after  it 
is  printed  when  the  LINK  command  is  executed  in  batch  mode 
(LINK/SUBMIT). 

By  default,  the  log  file  is  not  deleted. 

/LOG 

/NOLOG  (D) 

Controls  whether  a  list  of  all  the  units  included  in  the  executable  image 
is  displayed.  The  display  shows  the  units  according  to  the  order  of 
elaboration  for  the  program. 

By.  default,  a  list  of  all  the  units  included  in  the  executable  image  is  not 
displayed. 

(MAIN  (D) 

/NOMAIN 

Controls  where  the  image  transfer  address  is  to  be  found. 

The  /MAIN  qualifier  indicates  that  the  XD  Ada  unit  specified  deter¬ 
mines  the  image  transfer  address,  and  hence  is  to  be  a  mam  program. 

The  /NOMAIN  qualifier  indicates  that  the  image  transfer  address  comes 
from  one  of  the  files  specified,  and  not  from  one  of  the  XD  Ada  units 
specified. 

By  default  (/MAIN),  only  one  XD  Ada  unit  can  be  specified,  and  that 
unit  must  be  an  XD  Ada  main  program. 

lMAP[»fll9'Spec] 

/NOMAP  (D) 

Controls  whether  the  builder  creates  an  image  map  file  and  optionally 
provides  a  file  specification  for  the  file.  The  default  directory  for 
the  image  map  file  is  the  current  directory.  The  default  file  name 
comprises  up  to  the  first  39  characters  of  the  first  unit  name  specified. 
The  default  file  type  is  MAP.  No  wildcard  characters  are  allowed  in  the 
file  specification. 

If  neither  the  /BRIEF  nor  the  /FULL  qualifier  is  specified  with  the  /MAP 
qualifier,  /BRIEF  is  assumed. 

By  default,  no  image  map  file  is  created. 
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Implementation-Dependent 

Characteristics 


This  appendix  describes  Version  1.2  additions  to  the  range  of 
implementation-dependent  pragmas,  and  enhancements  to  the  func- 
tiortality  of  Package  TEXT.IO.  It  supplements  information  supplied  in 
the  Version  1.0  version  of  this  appendix. 


F.1  Implementation-Dependent  Pragmas 

XD  Ada  MC68020  Version  1.2  supplies  three  new  pragmas,  DIRECT_ 
INTERRUPT. ENTRY,  IDENT  and  TIME.SLICE.  In  the  following  full 
list  of  supported  pragmas,  references  refer  to  sections  in  the  XD  Ada 
MC68020  Supplement  to  the  Ada  Language  Reference  Manual,  unless  updated 
by  sections  supplied  in  this  manual. 

•  CALL.SEQUENCE.FUNCnON  (see  Annex  B) 

•  CALL.SEQUENCE.PROCEDURE  (see  Annex  B) 

•  DIRECT.INTERRUPT.ENTRY  (see  Section  13.5.1) 

•  EXPORT.EXCEPTION  (see  Section  13.9a.3.2) 

•  EXPORT.FUNCnON  (see  Section  13. 9a.  1.2) 

•  EXPORT.OBJECT  (see  Section  13. 9a. 2. 2) 

•  EXPORT.PROCEDURE  (see  Section  13. 9a.  1.2) 

•  IDENT  (see  Annex  B) 

•  IMPORT.EXCEPnON  (see  Section  13.9a.3.1) 

•  IMPORT.FUNCnON  (see  Section  13.9a.l.l) 
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F.1  Implementation-Dependent  Pragmas 

XD  Ada  provides  the  following  pragmas,  which  are  defined  elsewhere 
in  the  text.  In  addition,  XD  Ada  restricts  the  predefined  language 
pragmas  INLINE  and  INTERFACE,  provides  pragma  VOLATILE  in 
addition  to  pragma  SHARED,  and  provides  pragma  SUPPRESS.ALL  in 
addition  to  pragma  SUPPRESS.  See  Annex  B  for  a  descriptive  pragma 
summary. 

•  CALL.SEQUENCE.FUNCnON  (see  Annex  B) 

•  CALL_SEQUENCE_PROCEDURE  (see  Annex  B) 

•  EXPORT.EXCEPTION  (see  Section  13.9a.3.2) 

•  EXPORT.FUNCnON  (see  Section  I3.9a.l.2) 

•  EXPORT_OBJECT  (see  Section  13.9a.2.2) 

•  EXPORT.PROCEDURE  (see  Section  13.9a. 1.2) 

•  IMPORT_EXCEPTION  (see  Section  13.9a.3.1) 

•  IMPORT.FUNCnON  (see  Section  13.9a.l.l) 

•  IMPORT.OBJECT  (see  Section  13.9a.2. 1) 

•  IMPORT_PROCEDURE  (see  Section  13.9a.l.l) 

•  LEVEL  (see  Section  13.5.1) 

•  LINK_OPTION  (see  Annex  B) 

•  SUPPRESS. ALL  (see  Section  11.7) 

•  TITLE  (see  Annex  B) 

•  VOLATILE  (see  Section  9.11) 


F.2  Implementation-Dependent  Attributes 

XD  Ada  provides  the  following  attributes,  which  are  defined  elsewhere 
in  the  text.  See  Appendix  A  for  a  descriptive  attribute  summary. 

•  BIT  (see  Section  13.7.2) 

•  MACHINE.SIZE  (see  Section  13.7.2) 

•  TYPE.CLASS  (see  Section  13.7a.2) 
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•  lMPORT_OBJECT  (see  Section  13. 9a. 2.1) 

•  IMPORT_PROCEDURE  (see  Section  13.9a. 1.1) 

•  LEVEL  (see  Section  13.5,1) 

•  UNK.OPnON  (see  Annex  B) 

•  SUPPRESS_ALL  (see  Section  11.7) 

•  TITLE  (see  Annex  B) 

•  TIME.SLICE  (see  Section  9.8a) 

•  VOLATILE  (see  Section  9.11) 


F.8.1  The  Package  TEXTJO 

The  package  TEXT_IO  conforms  to  the  specification  given  in  the 
Reference  Manual  for  the  Ada  Programming  Language.  Package  TEXT_IO,  as 
supplied  by  XD  Ada  MC68020  Version  1.2,  has  changed  as  follows; 

•  The  Run-Time  System  now  supports  asynchronous  input-output 
operations,  where  a  TEXT_IO  operation  will  cause  only  the  task 
that  performs  the  operation  to  be  suspended  awaiting  its  com¬ 
pletion,  rather  than  all  the  tasks  in  the  program.  You  enable  this 
faciUty  by  compiling  the  file  XDADASTARGET.SOLTRCEiASYNC. 
TERMINAL_IO.ADA  into  your  program  library,  as  described  in 
the  XD  Ada  MC6802Q  Version  1.2  New  Features  Manual.  You  dis¬ 
able  asynchronous  TEXT_IO  derations  by  compiling  the  file 
XDADA$TARGET_SOLfRCE:TERMINAL_IO.ADA  into  your  pro¬ 
gram  library. 

•  Support  is  provided  for  target  input-output  to  be  directed  to  logical 
input  and  output  streams  on  the  host.  This  facility  is  available  for 
both  the  XDDEBUG  and  XDRUN  commands. 

Input  and  output  are  buffered.  For  input,  all  characters  up  to  an 
end  of  line  or  end  of  page  are  made  available  to  the  target  program 
before  further  characters  are  read.  For  output,  the  buffer  is  flushed 
following  an  end  of  line  or  end  of  page.  See  the  XD  Ada  MC68020 
Version  1.2  New  Features  Manual  for  details  of  the  TEXT.IO  data 
objects  that  control  this  behavior. 

Note  that  if  XDADASINPUT  and  XDADASOUTPUT  are  defined  but 
opening  the  file  gives  an  error,  for  example  the  file  does  not  exist, 
the  filename  is  invalid  or  no  read/write  permission  is  assigned,  the 
file  is  treated  as  empty. 
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F.3  Specification  of  the  Package  System 

The  package  SYSTEM  for  the  MC68020  is  as  follows: 

paekae*  SYSTEM  la 

typa  NAME  la  (MC68020); 

SVSTBM_NAMB  i  eaaataat  NAME  MC68020; 

’  STORAGE^UNIT  i  eoaataak  8; 

MEMORY_SIze  1  eoaataat  i"  2»*31-l; 

MIN.INT  i  eaaataat  -(2*«31); 

MAX_INT  t  eaaataat  2»»31-1; 

MAX.DIGITS  t  eaaataat  18; 

MAX.MANTISSA  :  eaaataat  31; 

FINS_OELTA  t  eaaataat  i-  2.0**(-31); 

TICK  '  I  eaaataat  162.Se-6; 

aaktypa  PRIORITY  la  INTEGER  raaga  0  ..  IS; 

aaktypa  LEVEL  la  INTEGER  raaga  0  ..  7; 

—  Addraaa  typa 

typa  ADDRESS  la  prlvata; 

AODRESS^ZERO  I  eaaataat  ADDRESS; 
typa  ADDRESS_INT  la  raaya  MtM_INT  . .  MAX_:ST; 

(aaatlaa  TO.ADDRESS  (X  t~ADDRBSS_INT) 

faaetlaa  TO_A00RBSS  (X  t  (univeraal_inteqer ) ) 

(aaatlaa  To'adDRESS.INT  (X  i  ADDRESS) 

(aaatlaa  ’«*  ILEFT  t  ADDRESS;  RIGHT  ;  AOOR£SS_INT)  ratan  ADDRESS; 

(aaatlaa  ***  (LEFT  s  ADDRBSS^INT;  RIGHT  :  AODRESsT  ratara  ADDRESS; 

(aaatlaa  (LEFT  i  ADDRESsT  RIGHT  :  ADDRESS)  ratara  ADDRESS. I NT; 

(aaetiea  *-*  (LEFT  t  ADDRESS;  RIGHT  :  ADDRESS.INT)  ratara  ADDRESS; 

—  (aaatlaa  *>*  (LEFT,  RIGHT  i  ADDRESS)  ratara  BOOLEAN; 

••  (aaetiea  */•*  (LEFT,  RIGHT  >  ADDRESS)  raters  BOOLEAN; 

(aactlaa  *<*  (LEFT,  RIGHT  i  ADDRESS)  ratara  BOOLEAN; 

(aaetiea  ’<>*  (LEFT,  RIGHT  t  ADDRESS)  ratara  BOOLEAN; 

(aaatlaa  *>*  (LEFT,  RIGHT  t  ADDRESS)  ratara  BOOLEAN; 

(aaatlaa  *>«*  (LEFT,  RIGHT  :  ADDRESS)  ratara  BOOLEAN; 

—  Note  that  bocauaa  ADDRESS  is  a  privaca  typa 

—  the  Cuncciona  and  '/-•  are  already  available 

Generic  tunctiona  used  to  access  memory 
gaaarle 

typa  TARGET  la  private; 

(aaetiea  FETCH.FROM.AOORESS  (A  ADDRESS)  ratara  TARGET; 

paaerie 

type  TARGET  la  private; 

preeadare  ASSIGN.TO  ADDRESS  (A  i  ADDRESS;  T  I  TARGET); 
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ratara  ADDRESS; 
ratara  ADDRESS; 
ratara  ADDRESS  INT; 


trr*  ■:ypb_ciass  is  (Typb  class  enumeraticm, 

TYPB^CLASSI INTEGER, 
TYPE~CLASS~  r I X  ED_  PO  r  NT , 

type2class”floatIng_point, 

typb^class'array, 

typbIclass^hecoro, 

typb'class^access, 

typb'class^task, 

TYPB^CLASs'aDORESS) ; 


XO  Ada  hardwara-oriancsd  typaa  and  £unctlans 


typ*  BIT_ARRAY  la  array  ( INTEGER  rasya  <> 
pra«M  PACK  (  ai  T_ARRAy ) ; 

sahtypa  BIT_ARRAY_8  la  BIT_ARHAY  (0  ..  7>; 

svhtypa  BIT.ARRAY^IE  la  BIT.ARRAY  (0  ..  IS); 

aahtypa  BIT_ARRAY~32  la  aiT~ARRAY  (0  ..  31); 

saktyps  BIT.ARRAyIsI  la  BIT^ARRAY  (0  ..  63); 

typa  UNSXGNBD.BYTi  la  ru«s  0  ..  2SS; 
far  UNSIGNBd'bytB'SIZB  uaa  8; 

taaatlaa  *noc'  (LEFT  t  UNSIGNB0_8YTB) 

faaatlaa  *and*  (LEFT,  RIGHT  i  UNSIGNEO^BYTE) 

faaatloa  *or’  (LEFT,  RIGHT  t  UNSIGNE0~8YTE) 

faaatlaa  'xor*  (LEFT,  RIGHT  >  UNSIGNEO~BYTE) 


)  of  BOOLEAN; 


ratura  UNSIGNBD_BYTB; 
rstura  UNSIGNED^BYTE; 
ratura  UNSIGNBo'bytb; 
ratura  UNSIGNEd'byTB; 


faaatlaa  TO_UNSIGNBO_aYTB  (X  :  BIT_ARRAY_a)  ratura  UNSIGNBD_aYTE; 
faaatlaa  TO~aiT_ARRAY_8  (X  i  UNSIGNED_8YTE)  ratura  BIT_ARRAyI8; 


typa  UNSIGNEO_BYTB_ARRAY  la  array  (INTEGER  raaga  <>)  of  UNSIGNBO_BYTE; 

typa  UNSIGNEO.WORO  la  raaga  0  ..  65S3S; 
far  UNSIGNEo'wORO'SIZE  uaa  16; 


faaatlaa  'not*  (LEFT  i  UNSIGNBD.WORO)  ratura  UNSIGNBD.uoro; 

faaatlaa  ‘and*  (LEFT,  RIGHT  <  UNSIGNEo'moro)  ratura  unsignbo'woro; 
faaatlaa  *or*  (LEFT,  RIGHT  i  UNSIGNBO^horD)  ratura  UNSlGNBoIwORO; 
faaatlaa  *xor*  (LEFT,  RIGHT  i  UNSIGNBO.MORO)  ratura  UNSIGNED^HORO; 

faaatlaa  TO  UNSIGNED.WORO  (X  s  8IT_ARRAY_16 )  ratura  UNSIGNEO.WORO; 
faaatlaa  To28IT_ARRAY_l6  (X  «  ONsIgnED.hORO)  ratura  BIT_ARRAY_16; 

typa  UNSIGNED.MORO.ARRAY  la  array  (INTEGER  raaga  <>)  af  UNSIGNED^lfORO; 


typa  UNSIGNBO_LONGHORO  la  raaga  MIN_INT  ..  HAX_INT; 
far  UNSIGNEO_LONGWORO‘SIZE  uaa  32; 

faaatlaa  'nof  (LEFT  i  UNSIGNED_LONGHORD)  ratara  UNSIGNED_LONGWORD; 

faaatlaa  ‘and*  (LEFT,  RIGHT  :  UNSIGNEO^LONGMORD)  ratura  UNSIGNED^LONGNORD; 

fuactlsa  'or*  (LEFT,  RIGHT  :  UNSIGNEo'lONGMORO)  ratura  UNSIGNEd'lONCWORD; 

faaatlaa  'xor*  (LEFT,  RIGHT  i  UNSIGNEO'lONGMQRO)  ratura  UNSIGNED'lONGWORD; 

faaatloa  T0_UHSIGNB0_L0NGH0R0  (X  :  BIT_ARRAY_32)  ratura  UNSIGNEO_LONGWORD; 
faaatloa  To3bIT_ARRAY_32  (X  :  UNSIGNED^WORD)  ratara  8 I T_ARRAY_ 3 2 ; 

typa  UNSIGNED.LONGHORO.ARRAY  la  array  (INTEGER  raaga  <>)  of  UNSIGNED.LONGWORO 
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--  Convancional  nanaa  i 

avbtypa  UNSIGNED, I 
aubtypa  UNSIGNEo'i 
aalitypa  UNSIGNED' 3 
SUbCypa  UNSIGNED~4 
auhtypa  UNSIGNED^S 
aubtypa  UNSIGNEo's 
aabtyp*  UNSIGNED^^ 
aabtypa  UNSIGNED' 9 
•  aabtypa  UNSIGNEd29 
aabtypa  UNSIGNED^IO 
aabtypa  UNSIGNED* 11 
aabtypa  UNSIGNED* 12 
aabtypa  UNSIGNEo3l3 
aabtypa  UNSIGNED* 14 
aabtypa  UNSIGNED* IS 
aabtypa  UNSIGNEO^IS 
aabtypa  UNSIGNEO^H 
aabtypa  UNSIGNED^IS 
aabtypa  UNSIGNED* 19 
aabtypa  UNSIGNED* 20 
aabtypa  UNSIGNtO~21 
aabtypa  UNSiaNED~22 
aabtypa  UNSIGNEd323 
aabtypa  UNSIGNED~24 
aabtypa  UNSIGNEd22S 
aabtypa  UNSIGNEO~26 
aabtypa  UNSIGNED~27 
aabtypa  UNSIGNED~2a 
aabtypa  UNSIGNEo329 
aabtypa  UNSIGNEd330 
aabtypa  UNSIGNED^Bl 

priaata 

— -  Not  ahown 

a*<  SYSTEM; 


or  static  suotypaa  ol 

la  UNSIGNED_LCNGWORO 
la  UNSIGNED^LCNGWOBO 
la  unsigneo'longworo 
la  unsigned'lcngword 
la  unsigneo'longworo 
la  unsigned^longword 

la  UNSIGNED^LCNGWORO 

la  unsigneo'longworo 
la  unsigneo'longworo 
la  unsigneo'longworo 

la  UNSIGNEO^LONCWORD 
la  UNSIGNEO^LCNGWORO 

la  unsigneo'longworo 
la  unsigneo'longworo 
la  unsigneo'longworo 
la  unsigneo^longworo 
la  unsigneo'longworo 
la  unsigneo'longworo 
la  unsigneo^longworo 
la  unsigneo'longworo 

la  UNSIGNEO^LONGWORo 

la  unsignbo^longword 
la  unsigneo'longworo 
la  unsigneo'longworo 
la  unsigneo'longworo 
la  unsigneo'longworo 

la  UNSIGNEO^LCNGWORO 
la  unsigneo'longworo 
la  unsigneo'longworo 
la  unsigneo'longworo 
la  unsigneo'longworo 


^Vpe 

UNS 1 

GNED_L>fJ 

raag* 

3 

i-i 

raoga 

C 

2-; 

raaga 

0 

2*»  3-1 

raaga 

0 

2*»  4-1 

raaga 

0 

5-1 

raaga 

0 

2**  6-1 

raaga 

0 

2**  7-1 

raaga 

0 

9-1 

raaga 

0 

9-1 

raaga 

0 

2*»l0-l 

raaga 

0 

2*»ll-l 

raaga 

0 

2*»12-1 

raaga 

0 

2*»13-1 

raaga 

0 

2*»14-l 

raaga 

0 

2*»15-1 

raaga 

0 

2»«16-l 

raaga 

0 

2*»17-l 

raaga 

0 

2»»18-l 

raaga 

0 

2«»19-1 

raaga 

0 

2*»20-l 

raaga 

0 

2**2I-1 

raaga 

0 

2»«22-l 

raaga 

0 

2*»23-l 

raaga 

0 

2*»24-l 

raaga 

0 

2«»25-l 

raaga 

0 

2**26-l 

raaga 

0 

2**27-l 

raaga 

0 

2*»28-l 

raaga 

0 

2**29-l 

raaga 

0 

2*»30-l 

raaga 

0 

2*»31-I 

F.4  Restrictions  on  Representation  Clauses 

The  representation  clauses  allowed  in  XD  Ada  are  length,  enumeration, 
record  representation,  and  address  clauses. 

In  XD  Ada,  a  representation  clause  for  a  generic  formal  type  or  a  type 
that  depends  on  a  generic  formal  type  is  not  allowed.  In  addition,  a 
representation  clause  for  a  composite  type  that  has  a  component  or 
suDcomponent  of  a  generic  formal  type  or  a  type  derived  from  a  generic 
formal  ^e  is  not  allowed. 
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Restrictions  on  length  clauses  are  specified  in  Section  13.2;  restrictions 
on  enumeration  representation  clauses  are  specified  in  Section  13.3;  and 
restrictions  on  record  representation  clauses  are  specified  in  Section 


F.5  Conventions  for  Implementation-Generated  Names 
Denoting  Implementation-Dependent  Components  in 
Record  Representation  Clauses 

XD  Ada  does  not  allocate  implementation-dependent  components  in 
records. 


F.6  Interpretation  of  Expressions  Appearing  in  Address 
Clauses 

Expressions  appearing  in  address  clauses  must  be  of  the  type  ADDRESS 
defined  in  pacl^ge  SYSTEM  (see  Section  13.7a.l  and  Section  F.3). 

XD  Ada  allows  address  clauses  for  variables  (see  Section  13.5).  For 
address  clauses  on  vanables.  the  address  expression  is  interpreted  as  a 
Motorola  full  32-bit  address. 

XD  Ada  supports  address  clauses  on  task  entries  to  allow  interrupts  to 
cause  a  reschedule  directly.  For  address  clauses  on  task  entries,  the 
address  expression  is  interpreted  as  a  Motorola  exception  vector  offset. 

In  XD  Ada  for  MC68020,  values  of  type  SYSTEM.ADDRESS  are  inter¬ 
preted  as  integers  in  the  range  0  ..  2^^  -1.  As  SYSTEM.ADDRESS  is 
a  private  type,  the  only  operations  allowed  on  objects  of  this  type  are 
those  given  in  package  SYSTEM. 


F.7  Restrictions  on  Unchecked  Type  Conversions 

XD  Ada  supports  the  generic  function  UNCHECKED_CONVERSION 
with  the  restrictions  given  in  Section  10.3.2. 
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F.8  Impiementation-Dependent  Characteristics  of 
Input-Output  Packages 


The  packages  SEQUENTIAL.IO  and  DIRECT_IO  are  implemented  as 
null  packages  that  conform  to  the  specification  given  in  the  Reference 
Manual  for  the  Ada  Programming  Language.  The  packages  raise  the  ex¬ 
ceptions  specified  in  Chapter  14  of  the  Reference  Manual  for  the  Ada 
Programming  Language.  The  three  possible  exceptions  that  are  raised  by 
these  packages  are  given  here,  in  the  order  in  which  they  are  raised. 


Exception 

When  Raised 

STATUS.ERROR 

Raised  by  an  attempt  to  operate  upon  or  dose  a  file 
that  is  not  open  (no  files  can  be  opened). 

NAME.ERROR 

Raised  if  a  file  name  is  given  with  a  call  of  CREATE 
or  OPEN. 

USE.ERROR 

Raised  if  exception  STATUS.ERROR  is  not  raised. 

MODE.ERROR  cannot  be  raised  since  no  file  can  be  opened  (therefore 
it  cannot  have  a  current  mode). 

The  predefined  package  LOW_LEVEL_IO  is  not  provided. 


F.8.1  Th«  Package  TEXTJO 

The  package  TEXT.IO  cortforms  to  the  specification  given  in  the 
Reference  Manual  for  the  Ada  Programming  Language.  String  input- 
output  is  implemented  as  defined.  File  input-output  is  supported  to 
STANDARD.INPUT  and  STANDARD.OUTPUT  only.  The  possible 
exceptions  that  are  raised  by  package  TEXT.IO  are  as  follows: 
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Exception 

When  Raised 

STATUS. ERROR 

Raised  by  an  attempt  to  operate  upon  or  close  a  file 
that  is  not  open  tno  files  can  be  opened). 

NAME.ERROR 

Raised  if  a  file  name  is  given  with  a  call  of  CREATE 
or  OPEN. 

MODE.ERROR 

Raised  by  an  attempt  to  read  from,  or  test  for 
the  end  of.  STANDARD  OUTPUT,  or  to  write  to 
STANDARD.INPUT. 

END.ERROR 

Raised  by  an  attempt  to  read  past  the  end  of 
STANDARD.INPUT. 

USE.ERROR 

Raised  when  an  unsupported  operation  is  attempted, 
that  would  otherwise  be  legal. 

The  type  COUNT  is  defined  as  follows; 

trp«  COUNT  la  raa«a  0  ..  INTBGBR' LAST: 

The  subtype  FIELD  is  defined  as  follows: 

typa  FIBLO  la  INTBGBR  raa«a  0  ..  132; 


F.8.2  The  Package  lO.EXCEPTiONS 

The  specification  of  the  package  IO_  EXCEPTIONS  is  the  same  as  that 
given  in  the  Reference  Manual  for  the  Ada  Programming  Language. 


F.9  Other  Implementation  Characteristics 

Implementation  characteristics  associated  with  the  definition  of  a  main 
program,  various  numeric  ranges,  and  implementation  limits  are  sum-  - 
marized  in  the  following  sections. 


F.9.1  Definition  of  a  Main  Program 

Any  library  procedure  can  be  used  as  a  main  program  provided  that  it 
has  no  formal  parameters. 
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F.9.2  Values  of  Integer  Attributes 

The  ranges  of  values  for  integer  types  declared  in  package  STANDARD 
are  as  follows; 

SHORT.SHORTJNTEGER  -2'  ..  2^  -I  (-128  ..  127) 

SHORT.INTEGER  -2‘*  ..  2'"  -1  (-32768  ..  32767) 

INTEGER  -2^‘  ..  2-*'  -I  (-2147483648  ..  2147483647) 

For  the  package  TEXT_IO,  the  range  of  values  for  types  COUNT  and 
FIELD  are  as  follows: 

COUNT  0  ..  2**  -1  (0 ..  2147483647) 

FIELD  0..  132 


F.9.3  Values  of  Floating-Point  Attributes 

Floating-point  types  are  described  in  Section  3.5.7.  The  representation 
attributes  of  floating-point  types  are  summarized  in  the  following  table: 
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FLOAT 

LONG.FLOAT 

LONG.LONC.FLOAT 

DIGITS 

6 

15 

18 

SIZE 

32 

64 

96 

MANTISSA 

21 

51 

61 

EMAX 

84 

204 

244 

EPSILON 

2-:o 

2-50 

2->o 

SMALL 

2-“ 

2-20$ 

2-2*5 

LARGE 

2**-2^ 

220*  _2'^ 

22m_2'“ 

SAFE.EMAX 

125 

1021 

16382 

SAFE.SMALL 

2-12* 

2- 1021 

2-i*3a3 

SAFE.IARGE 

2l2S_2'<H 

2(021  _2*™ 

2(*3U_2(*32I 

RRST 

-(2'«-2‘«) 

LAST 

2i2i_2HM 

2l024_2WI 

2l*SM_2l*)20 

MACHINE.RADIX 

2 

2 

2 

MACHINE.MANTISSA 

24 

53 

64 

MACHINE.EMAX 

128 

1024 

16384 

MACHINE.EMIN 

-125 

-1021 

-16382 

MACHINE.ROUNDS 

FALSE 

FALSE 

FALSE 

MACHINE.OVERFLOWS 

FALSE 

FALSE 

FALSE 
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F.9.4  Attributes  of  Type  DURATION 


The  values  of  the  significant  attributes  of  type  DURATION  are  as 
follows: 


DURATION '  DELTA 
DURATION 'SMALL 
DURATION 'FIRST 
DURATION '  LAST 


l.E-4 

2#1.0#E-U 

-131072.0000 

131071.9999 


(lO-*) 

(2-'*) 

(-2'0 

(2'^- 'DELTA) 


F.9.5  Implementation  Limits 


Limit 

Description 

255 

Maximum  identifier  length  (number  of  characters) 

255 

Maximum  number  of  characters  in  a  source  line 

2"» 

Maximum  number  of  Library  units  and  subunits  in 
closure' 

a  compilation 

2'* 

Maximum  number  of  library  units  and  subunits  in 
closure^ 

an  execution 

2‘*  -1 

Maximum  number  of  enumeration  literals  in  an  enumeration 
type  definition 

2'*  -1 

Maximum  number  of  lines  in  a  source  file 

2*'  -1 

Maximum  number  of  bits  in  any  object 

2“  -1 

Maximum  number  of  exceptions 

'Th«  compiUtion  closure  of  a  given  unit  is  the  total  set  of  units  that  the  given  unit 
depends  on,  directly  and  indirectly 

^The  execution  closure  of  a  given  unit  is  the  compilation  closure  plus  all  associated 
secondary  units. 
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Chapter  13 

Representation  Clauses  and 
Implementation-Dependent 

Features 


Supplementary  XD  Ada  information  is  provided  for  Sections  13.1,  13.2, 
13.3,  13.4,  13.5,  13.5.1.  13.7,  13.7.1,  13.7.2,  13.7.3,  13.8,  13.9,  13.10.1 
and  13.10.2.  Two  additional  sections.  Section  13.7a  and  Section  13.9a, 
provide  XD  Ada  information  on  the  package  SYSTEM  and  on  the  XD 
Ada  import  and  export  pragmas. 


13.1  Representation  Clauses 

The  following  information  supplements  paragraphs  4  and  8: 

In  XD  Ada,  an  address  clause  can  only  apply  to  a  variable  or  a  single 
entry;  an  address  clause  cannot  apply  to  a  constant,  subprogram, 
package,  or  task  unit.  See  Section  13.5  for  further  explanation. 

The  following  information  supplements  paragraph  13: 

Fra^a  PACK  is  implemented  in  XD  Ada.  As  the  behavior  of  pragma 
PACK  is  implementation  dependent,  users  are  advised  to  use  represen¬ 
tation  clauses  to  ensure  a  particular  representation  across  targets. 

In  XD  Ada,  all  array  and  record  components  are  aligned  on  byte 
boundaries  by  default;  the  effect  of  pragma  PACK  on  a  record  or 
array  is  to  cause  those  components  that  are  packable  to  be  allocated  in 
adjacent  bits  without  regard  to  byte  boundaries.  Whether  any  particular 
component  is  packable  depends  on  the  rules  for  its  type;  the  XD 
Ada  MC68020  Run-Time  Reference  Manual  gives  information  on  which 
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types  can  be  packed  as  components  of  composite  types,  as  well  as 
information  on  how  these  types  are  packed. 

A  record  component  that  begins  a  variant  is  always  allocated  at  the  next 
b3de  boundary;  a  variant  that  begins  on  other  than  a  byte  boundary  can 
be  obtained  only  with  a  record  representation  clause. 

XD  Ada  provides  no  additional  representation  pragmas. 

The  following  information  supplements  paragraph  14: 

XD  Ada  does  not  allow  a  representation  clause  for  a  type  that  depends 
on  a  generic  formal  type.  A  type  depends  on  a  generic  formal  type 
if  it  has  a  subcomponent  of  a  generic  formal  type  or  a  subcomponent 
that  depends  on  a  generic  formal  type,  or  if  it  is  derived  from  a  generic 
formal  type  or  a  type  that  depends  on  a  generic  formal  type. 


13.2  Length  Clauses 

The  follotving  information  supplements  paragraph  6: 

In  XD  Ada,  for  a  discrete  type,  the  given  size  must  not  exceed  32 
(bits).  The  given  size  becomes  the  default  allocation  for  all  objects  and 
components  (in  arrays  and  records)  of  that  type.  However,  sizes  of 
objects  may  be  increased  by  the  compiler  for  optimization  purposes. 

For  integer  and  enumeration  types,  the  given  size  affects  the  internal 
representation  as  follows:  for  integer  types,  high  order  bits  are  sign- 
extended;  for  enumeration  types,  the  high  order  bits  may  be  either 
zero-  or  sign-extended  depending  upon  t!  le  base  representation  that 
is  selected.  For  all  other  types,  the  given  size  must  equal  the  size  that 
would  apply  in  the  absence  of  a  size  specification. 

The  following  information  supplements  paragraph  8: 

The  specification  of  a  collection  size  is  interpreted  as  follows.  If  the 
value  of  the  expression  is  greater  than  or  equal  to  zero,  the  specified 
size  (representing  the  number  of  bytes  in  the  collection)  is  rounded  up 
to  the  longword  boundary  nearest  (4  bytes),  and  is  then  used  as  the 
initial  size  of  the  collection;  the  collection  is  not  extended  should  that 
iiutial  allocation  be  exhausted.  In  the  absence  of  a  T'STORAGE.SIZE, 
no  storage  is  initially  allocated  for  the  collection;  storage  is  allocated 
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from  the  heap  as  needed,  until  all  heap  memory  is  exhausted.  If  the 
value  is  less  than  zero,  the  exception  CONSTRAINT_ERROR  is  raised. 

The  following  information  supplements  paragraph  10: 

A  task  storage  specification  overrides  the  default  task  storage  size.  The 
specification  is  interpreted  as  follows.  If  the  value  of  the  expression 
is  greater  than  zero,  the  specified  size  is  rounded  up  to  the  nearest 
longword  boundary  (4  bytes),  and  this  determines  the  number  of 
storage  units  (b)des)  to  be  allocated  for  an  activation  of  the  task  of  the 
^ven  type.  In  the  absence  of  a  T'STORACE.SIZE,  a  default  allocation 
is  used.  If  the  value  is  less  than  zero,  the  exception  CONSTRAINT. 
ERROR  is  raised. 

The  following  information  supplements  paragraphs  8  and  10: 

NOTE 

The  XD  Ada  MC68Q20  Run-Time  Reference  Manual  discusses 
task  and  access  type  storage  and  storage  allocation  in  more 
detail. 

The  following  information  supplements  paragraph  12: 

In  XD  Ada,  arbitrary  values  of  small  are  accepted.  The  default  value  of 
small  is  the  largest  power  of  two  that  is  not  greater  than  the  given  delta 
(see  Section  3.5.9). 

If  small  is  specified  (see  Section  3.5.9  (LRM)),  the  specified  value  must 
not  exceed  the  default.  For  example; 

(•r  HY.riXSO'SMALL  uaa  0.001; 

This  example  is  a  legal  specification  for  the  declaration  of  MY.FIXED 
because  the  value  specified  for  small  (0.001)  is  less  than  the  delta  (0.1) 
and  that  also  satisfies  the  specified  range  (0.0..  1.0). 


13.3  Enumeration  Representation  Ciauses 

The  following  information  supplements  paragraph  4: 

In  XD  Ada,  the  only  specific  restriction  on  enumeration  representation 
clauses  is  that  each  expression  for  an  integer  code  must  have  a  value  in 
the  range  MIN.INT  ..  MAX.INT. 
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13.4  Record  Representation  Clauses 


The  following  information  supplements  paragraph  4: 

For  statically  allocated  objects  and  for  objects  allocated  from  a  collection 
in  XD  Ada,  the  simple  expression  in  an  alignment  clause  must  be 
a  power  of  two.  The  upper  limit  is  2^' .  The  alignment  then  occurs 
at  a  location  that  is  a  number  of  bytes  times  the  value  of  the  simple 
expression;  a  value  of  2  causes  word  alignment,  a  value  of  4  causes 
longword  alignment,  and  so  on. 

Further  restrictions  apply  for  objects  declared  within  a  subprogram, 
where  XD  Ada  restricts  the  alignment  to  mod  1.  In  other  words,  stack- 
allocated  objects  can  only  be  byte  aligned. 

Bit-alignable  representation  clauses  are  provided  for  discrete  types, 
arrays  of  discrete  types,  and  record  types. 

See  the  XD  Ada  MC6802Q  Run-Time  Reference  Manual  for  information  on 
how  objects  are  allocated. 

The  following  information  supplements  paragraph  5: 

A  component  clause  specifies  the  storage  place  of  a  component  relative 
to  the  start  of  the  record.  In  XD  Ada  for  MC68020  targets,  the  size  of  a 
storage  unit  (SYSTEM. STORAGE. UNIT)  is  eight  bits  (one  byte).  If  the 
number  of  bits  specified  by  the  range  is  sufficient  for  the  component 
subtype,  the  requested  size  and  placement  of  the  field  is  observed  (and 
overlaps  storage  boundaries  if  necessary);  otherwise,  the  specification  is 
Ulegal.  For  a  component  of  a  discrete  type,  the  number  of  bits  must  not 
exceed  32;  for  a  component  of  any  other  type,  the  size  must  not  exceed 
the  actual  size  of  the  component.  See  the  XD  Ada  MC68020  Run-Time 
Reference  Manual  for  information  about  determining  the  number  of  bits 
that  are  sufficient  for  any  given  subtype. 

Component  values  in  XD  Ada  are  biased  when  a  component  clause 
requires  a  very  small  component  storage  space;  each  value  stored 
is  the  unsigned  quantity  formed  by  subtracting  COMPONENT. 
SUBTYPE 'FIRST  from  the  original  value.  See  the  XD  Ada  MC68020 
Run-Time  Reference  Manual  for  more  detailed  information. 

Component  clauses  in  XD  Ada  are  restricted  as  follows.  Any  com¬ 
ponent  that  is  not  packable  must  be  allocated  on  a  byte  boundary. 
Components  that  are  packable  can  be  allocated  without  restriction.  See 
the  XD  Ada  MC68020  Run-Time  Reference  Manual  for  a  definition  and 
description  of  packable  components. 
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The  following  information  supplements  paragraph  6: 

Components  named  in  a  component  clause  are  allocated  first;  then, 
unnamed  components  are  allocated  in  the  order  in  which  they  are 
written  in  the  record  type  declaration.  Variants  can  be  overlapped.  If 
pragma  PACK  is  specified,  packed  allocation  rules  (see  Section  13.1) 
are  used;  otherwise,  unpacked  allocation  is  used. 

The  following  information  supplements  paragraph  8: 

XD  Ada  generates  no  implementation-dependent  components  or 
names. 

The  following  information  supplements  the  Notes  section: 

The  example  of  record  representation  and  address  clauses  in  the 
Reference  Manual  for  the  Ada  Programming  Language  is  not  relevant  for 
XD  Ada  as  it  assumes  that  type  ADDRESS  is  represented  in  24  bits, 
whereas  in  XD  Ada  type  ADDRESS  is  represented  in  32  bits.  The 
following  example  is  appropriate  to  XD  Ada: 

Example: 

trp*  CONOIIION_CODB  la  (X,M,Z,V,C); 

tr»*  COMDITION_COOES  la  array  (CONDITtON_COOB)  ot  BOOLEAN; 
pra«M  PACK  (CONOITION.COOBS); 

tyya  PROGRAM_STATUS_WOBD  la 

raaar4 


TRACB.BNABLB 

tNTBGBR  raaga 

0  . 

.  3; 

SUPBRV I SOR_STATE 

BOOLEAN; 

INTERRUPT_iTATE 

BOOLEAN; 

intbhropt'mask 

t 

INTEGER  raaya 

0  . 

.  ,  7* 

CC 

f 

CONDITrOM_CODES; 

and  raaard; 

far  PRCWRAM_STATUS_WOBO  ttaa 
raaard  at  mod  1; 

TRACI_eNABLe  at  0  ran«a  0 

SUPBRVISOR.STATB  at  0  raaya  2 

INTBRRUPT_iTATB  at  0  raaffa  3 

INTBRRUPT^MASK  at  0  rmagm  5 

CC  at  0  raafo  11 

aad  raeard; 

far  PROGRAI1_STATUS_WORD'SIZB  uaa  2  •  SYSTEM.  STORAGB_UNIT; 

Note  on  the  axampio: 

The  record  representation  clause  defines  the  record  layout.  The  length 
clause  guarantees  that  exactly  two  storage  units  are  used. 


13.4  Record  Reprdtdntatton  Ciausds 
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Component  Specification  Example: 


■ubtypa  S  la  INTEGER  ranya  10 

typa  RBC  la 
raeerd 
X  I  S; 

Y  t  S; 
aad  raeord; 

far  RBC  uaa 
caeard 

X  afe  0  raaya  0  ..  3; 

Y  at  0  raa«a  4  . .  4 ; 


aad  racard; 


13; 


leqal  because  4  bita 
are  sufficient 
iileqal  because  1  bit  is 
not  enough  to  represent 
an  integer  of  subtype  S 


Notes  on  the  example: 

The  subtype  declaration  in  this  example  implies  an  integer  with  a  min¬ 
imum  size  of  four  bits.  However,  the  components  X  and  Y  of  subtype 
S  are  biased  and  can  be  stored  in  only  two  bits.  The  component  clause 
for  X  is  legal  because  it  requires  at  least  the  minimum  number  of  bits 
required  for  the  integer  subtype;  the  component  clause  for  Y  is  illegal 
because  it  does  not  allow  enough  bits  to  represent  the  integer  subtype. 


13.5  Address  Clauses 

The  following  information  supplements  paragraph  7: 

LiJee  VAX  Ada,  XD  Ada  supports  address  clauses. 

In  XD  Ada,  the  simple  name  must  be  the  name  of  a  variable.  XD  Ada 
does  not  allow  address  clauses  that  name  constants;  or  subprogram, 
package,  or  task  units. 

An  intermediate  pointer  is  created  only  if  the  resulting  address  is  not  a 
compile-time  constant. 

The  placement  of  an  address  clause  in  XD  Ada  must  follow  the  rules 
given  in  Section  13.1.  In  other  words,  the  clause  and  the  variable 
declaration  must  both  occur  immediately  within  the  same  declarative 
part  or  package  specification,  and  the  declaration  must  occur  before 
the  clause.  The  restrictions  for  forcing  occurrences  also  apply;  with 
respect  to  address  clauses,  any  occurrence  of  the  variable  name  after  its 
declaration  is  a  forcing  occurrence. 
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Address  clauses  are  not  allowed  in  combination  with  any  of  the  XD  Ada 
pragmas  for  importing  or  exporting  objects.  If  used  in  such  cases,  the 
pragma  involved  is  ignored. 

The  following  information  supplements  the  Notes  section: 

Also,  if  an  address  clause  is  specified  for  an  object  of  a  type  that  has 
been  declared  with  an  alignment  clause,  the  alignment  required  for  the 
address  is  checked  against  the  alignment  given  for  the  record  type.  If 
the  two  are  incompatible,  the  exception  PROGRAM.ERROR  is  raised. 

The  same  check  applies  to  a  type  that  contains  a  component  of  a  type 
that  has  been  declared  with  an  alignment  clause  (the  alignment  of  the 
component  forces  the  alignment  of  the  containing  type). 


13.5.1  Interrupts 

The  following  information  supplements  ail  of  this  section: 

Unlike  VAX  Ada,  XD  Ada  supports  interrupts.  The  address  in  the  use 
clause  is  the  address  of  the  interrupt.  The  address  is  interpreted  as  an 
offset  from  the  vector  base  register. 

XD  Ada  provides  the  additional  pragma  LEVEL.  This  pragma  is  given 
for  a  task  type,  or  single  task  of  anonymous  type,  and  gives  the  level  for 
its  interrupts. 

There  are  two  ways  an  interrupt  entry  can  be  handled,  according  to 
whether  or  not  the  task  has  a  pragma  LEVEL.  The  XD  Ada  MC68020 
Run-Time  Reference  Manual  gives  examples  of  interrupt  handlers. 

Tasks  with  interrupt  entries  but  no  pragma  run  at  interrupt  level  whilst 
accepting  an  interrupt  in  a  rendezvous.  Other  interrupts  of  the  same 
level  or  l^er  levels  are  inhibited.  It  is  possible  to  lose  interrupts  with 
this  method. 

Tasks  with  interrupt  entries  and  a  pragma  LEVEL  always  run  at  interrupt 
level,  whether  inside  or  outside  a  rendezvous.  This  enables  the  user  to 
avoid  losing  interrupts. 

An  interrupt  entry  to  a  task  with  the  pragma  behaves  like  an  ordinary 
entry  call.  An  interrupt  entry  to  a  task  with  no  pragma  behaves  like  a 
con^tiorul  entry  call.  If  there  is  an  accept  statement  waiting  for  the 
interrupt,  the  body  of  the  accept  statement  is  executed  immediately. 
When  the  body  is  complete,  the  task  is  inserted  in  the  ready  queue 
and  the  interrupt  completed  by  a  retum-from-interrupt  instruction.  The 
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accept  statement  can  make  excursions  into  other  routines,  and  can  even 
make  entry  calls,  but  must  not  suspend  the  task  before  the  interrupt 
is  dismissed,  otherwise  the  program  repeatedly  services  the  interrupt 
unsuccessfully. 

Writing  interrupt  handlers  in  XD  Ada  requires  detailed  knowledge  of 
the  behavior  of  the  target  computer's  interrupt  system.  It  is  not  possible 
simply  to  place  a  use  clause  on  an  entry  to  achieve  the  desired  effect. 


13.7  The  Package  System 

The  follo%ving  information  supplements  paragraph  1: 

XD  Ada  additions  to  the  package  SYSTEM  are  described  in  Section 
13.7a. 

The  following  information  supplements  paragraph  5: 

In  XD  Ada,  the  enumeration  literal  for  SYSTEM_NAME  is  MC68020. 

'The  following  information  supplements  paragraph  7: 

In  XD  Ada,  the  value  given  for  STORAGE.UNIT  must  be  8  (bits). 

'The  follo%ving  information  supplements  paragraph  9: 

In  XD  Ada,  the  number  given  for  MEMORY_SIZE  must  be  2*  *31-1. 
Like  VAX  Ada,  XD  Ada  does  not  provide  support  for  checking  or 
ensuring  that  the  given  size  is  not  exceeded. 

The  following  information  supplements  paragraph  11: 

As  with  VAX  Ada,  XD  Ada  imposes  no  further  limitations  on  these 
pragmas.  To  reduce  the  amount  of  recompilation  required,  XD  Ada 
identifies  those  units  that  have  a  real  dependence  on  the  values  affected 
by  these  pragmas;  only  such  units  must  be  recompiled.  In  particular, 
predefined  XD  Ada  packages  do  not  depend  on  the  values  affected  by 
these  pragmas,  and  none  require  recompilation  if  these  pragmas  are 
used. 


13.7a  XD  Ada  Additions  to  the  Package  SYSTEM 

In  addition  to  the  language-required  declarations  in  package  SYSTEM, 
XD  Ada  declares  the  operations,  constants,  types,  and  subtypes  de¬ 
scribed  in  the  follo%ving  sections. 
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13.7a. 1  Propertlas  of  the  Type  ADDRESS 

In  XD  Ada,  ADDRESS  is  a  private  type  for  which  the  following  opera¬ 
tions  are  declared; 

—  Addraaa  typa 

typ*  ADDRESS  la  prlvata; 


ADDRESS.ZERO  i  caaataat  ADDRESS; 

type  ADDRESS_INT  la  raaga  MIN.INT  ..  KAX.tNT; 

(aaatlM  TO.ADDRBSS  (X  t  AODRESS.tNT)  ratani  ADDRESS; 

fwaatlM  TO_ADDRESS  (X  i  (univeraal_inteqer > )  ratara  ADDRESS; 

faaatlM  TO_AODRESS_INT  (X  i  ADDRESS)  ~  ratara  ADDRESS_INT; 


faaatiaa  ■**  (LEFT  i  ADDRESS;  RIGHT  s  ADDRESS_INT)  ratara  ADDRESS; 

(aaatiaa  *♦’  (LEFT  i  ADDRESS_1NT;  RIGHT  :  ADDRESsT  ratara  ADDRESS; 

faaatiaa  *-*  (LEFT  i  ADDRESS?  RIGHT  t  ADDRESS)  ratara  ADDRESS  INT; 

faaatiaa  *-*  (LEFT  t  ADDRESS;  RIGHT  :  AODRBSS_INT)  ratara  ADDRESS? 


—  f«««tlM 

(LEFT, 

RIGHT 

ADDRESS) 

ratara 

BOOLEAN; 

—  ftMtloa 

(LEFT, 

RIGHT 

ADDRESS) 

ratara 

BOOLEAN; 

ftaotlOR 

-<•  (LEFT, 

RIGHT 

ADDRESS ) 

ratara 

BOOLEAN; 

faaatlM 

■<-•  (LEFT, 

RIGHT 

ADDRESS) 

ratara 

BOOLEAN; 

ftMtlra 

->■  (LEFT, 

RIGHT 

ADDRESS) 

ratara 

BOOLEAN; 

StMtlM 

*>-•  (LEFT, 

R.tGHT 

ADDRESS) 

r«tur« 

BOOLEAN; 

—  Nota  that  baeausa  ADDRESS  ia  a  privata  typa 

—  tha  funetiona  *-*  and  */•*  ara  alraady  availabla 

—  Ganarle  funetiona  uaad  to  aecaaa  naaocy 

Vaaarla 

typa  TARGET  la  privata; 

faaatiaa  FETCH^FROM. ADDRESS  (A  t  ADDRESS)  ratara  TARGET; 

faaarla 

typa  TARGET  la  privata; 

praaadara  ASSIGN.TO.ADDRESS  (A  t  ADDRESS;  T  <  TARGET); 

The  addition,  subtraction,  and  relational  functions  provide  arithmetic 
and  comparative  operations  for  addresses.  The  generic  subprograms 
FETCH.FROM.ADDRESS  and  ASSIGN.TO^  ADDRESS  provide  op¬ 
erations  for  reading  from  or  writing  to  a  given  address  interpreted  as 
having  any  desired  type.  ADDRESS.ZERO  is  a  deferred  constant  whose 
value  corresponds  to  the  first  (machine)  address. 


Pfopertlea  of  the  Type  AOORESS  I3.7a.t 


t3-0 


In  an  instantiation  of  FETCH.FROM.ADDRESS  or  ASSIGN.TO. 
ADDRESS,  the  actual  subtype  corresponding  to  the  formal  type  T 
must  not  be  an  unconstrained  array  type  or  an  unconstrained  type  with 
discriminants.  If  the  actual  subtype  is  a  type  with  discriminants,  the 
value  fetched  by  a  call  of  a  function  resulting  from  an  instantiation  of 
FETCH_FROM_ADDRESS  is  checked  to  ensure  that  the  discriminants 
satisfy  the  constraints  of  the  actual  subtype.  In  any  other  case,  no  check 
is  made. 

Example: 

X  t  INTBGBR; 

A  I  SYSTEM. AOOReSS  t-  X* ADDRESS;  —  leqal 

FETCH  la  aaw  FETCH_FROM_ADDReSS( INTEGER) ; 
vracadura  ASSIGN  la  aaw  ASStGN.TO^ADDRESSI INTEGER) ; 

X  I-  FETCHfA);  —  li)ta  -X  I-  A. all;* 

ASSIGNIA.X);  —  li)ca  -A. all  i»  X;* 


13.7a. 2  Typa  Clasa  Enumaration  Typa 

XD  Ada  declares  the  following  enumeration  type  for  identifying  the 
various  Ada  type  classes: 

tff  TYPE_CLASS  la  (TYPE_CIJVSS_ ENUMERATION, 

TYPb'cLASS” INTEGER, 

TYPB3cLASS~FIXED_POtNT, 

TY  PB^C  lass”  FLO  AtInG_^POINT, 

typb'class^array, 
type^class^record, 
typeIclass” access, 
type”class”task, 

TYPB'cLASs'aDDRBSS ) ; 

In  addition  to  the  usual  operations  for  discrete  types  (see  Section  3.5.5), 
XD  Ada  provides  the  attribute  TYPE_CI-ASS. 

For  every  type  or  subtype  T: 

T'TYPE_CLASS  Yields  the  value  of  the  type  class  for  the  full  type  of 
T.  If  T  is  a  generic  formal  type,  then  the  value  is  that 
for  the  corresponding  actual  subtype.  The  value  of 
this  attribute  is  of  the  type  TYPE.CLASS. 

This  attribute  is  only  allowed  if  its  unit  names  the  predefined  package 
SYSTEM  in  a  with  clause. 
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Example*: 

Given 


TYPB_CLASS_ INTEGER 
TYPE^CLASS^ARRAY 

type^class'floating  point 


13.7a.3  Hardwara-Orlentad  Types  and  Functions 

XD  Ada  declares  the  following  types,  subtypes,  and  functions  for 
convenience  in  working  with  MC68020  hardware-oriented  storage: 

—  XO  Ada  hardwara-orlantad  typas  and  functions 

tyt«  8IT_ARRAY  is  array  (INTEGER  raaya  <>>  of  BOOLEAN; 
f rayma  PACK( BIT^ARRAV ) ; 

aahtypa  aiT_ARRAY_8  is  BIT.ARRAY  (0  ..  7); 

sabtypa  BIt'arRAY^IS  ia  BIT.ARRAY  <0  ..  tS); 
aaktypa  BIT~ARRAY~32  la  BIT^ARRAV  (0  ..  31); 
saMypa  BIT'aRRAY^S^  la  BIT^ARRAY  (0  ..  63); 
tyf*  UNSIGNio.BYTi  is  rasfa  0  ..  2SS; 
far  UNSIGNEo'byTB'SIZE  aaa  8; 

faaatiaa  *not*  (LEfT  i  UNSIGNB0_8YTB)  ratura  UNSIGNED  BYTE; 

faaatiaa  'and*  (LErr,  RIGHT  t  UNSIGNBO.BYTE)  ratura  UNSIGNBo'bytB; 

faaatlaa  *ot'  (LEFT,  BIGHT  t  UNSIGNEO_BYTB)  ratura  UNSIGNEo'byTB; 

faaatlaa  *xor*  (LEFT,  RIGHT  i  UNSIGNBO.BYTB)  ratura  UNSIGNBD^BYTE; 

faaatiaa  TO_,UHSIGHEO_BYTE  (X  z  BIT_ARHAY_8)  ratura  UNSIGNED  BYTE; 
faaatlaa  T02bIT_ARRAY_8  |X  t  UNSIGNBO.BYTE)  ratura  BIT_ARRAY_8; 

tyf*  UNS1GHE0_BYTB_ARRAY  la  array  (INTEGER  raaya  <>)  of  UNSIGNED_8YTB! 
tyy*  UNSIGNBO^VORO  la  raaya  0  ..  esS3S; 
far  UNSIGNBO^hORD'SIZE  us«  16; 

faaatlaa  'not'  (LEFT  i  UNSIGNED^morD)  ratura  UNSIGNBD_hord; 

faaatlaa  'and*  (LEFT,  RIGHT  i  UNSIGNEo'morD)  ratura  UNSIGNEd'norD; 

faaatlaa  'or*  (LEFT,  RIGHT  l  UNSIGNED^WORD)  ratura  UNSIGNBD^HORD; 

faaatlaa  'xor'  (LEFT,  RIGHT  i  unsigned' WORD)  ratura  UNSIGNBd'morD; 

faaatiaa  TO  UNSIGNBO_NORO  (X  t  BIT_ARRAY_16 )  ratura  UNSIGNED  WORD; 
faaatlaa  To'biT.ARRAY.IS  (X  t  UNSlGNED^woRD)  rotara  BIT_ARRAy_l6 ; 
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tyya  HY_INT  la  raaya  1..10; 
typa  NEH.INT  la  saw  STRING ; 
yaekaga  PACK  la 

typa  PRIV  Is  prlvata; 
prirata 

typa  PRIV  la  saw  FLOAT; 
sad  PACK; 

then 

—  MY_1NT'TYPB_CLASS  equals 

—  NE1*_INT'TYPi  CLASS  equals 

—  PRIV TYPE  CLASS  equals 


typ*  UNStGNBD_WORO_ARRAY  !•  array  (INTEGER  raaga  <>)  o(  UNSIGNED  WORD; 


type  UNSIGNBD_LONGWORD  la  raapa  MIN_INT  ..  MAX_INT; 
(or  UNSIGNBD_LONGHORD‘SIZB  uao  32; 


(uaetloa  *noc* 
(uaetloB  'and* 
(uaetloa  *or* 
(uaetloa  *xor* 


(LBFT  I  ONSIGNED_LCNGWORD) 
(LEFT,  RIGHT  l  UNSIGNED^LONGWCRD) 
(LBrr,  RIGHT  I  UNSIGNBD~LONGHORD) 
(LBFT.  RIGHT  l  UNSIGNBD~LONGWORD) 


ratura  UNSIGNED_LOHGWORD; 
ratura  UNSIGNBD_LONGWORD; 
rotura  UNSIGNED_LONGWORD; 
ratura  UNSIGNBD~LONGHORD; 


(uaetloa  TO_UNSIGNBO_LONGWORD  (X  «  8IT_ARRAY_32 »  rotura  UNSIGNED  LONGWORO; 
(uaetloa  T0_B1T_ARRAY_32  (X  »  UNSlGNED~WORD>“rotura  BIT_ARRAY_327 

UNSIGNBO_LONGWORD_ARRAY  la  array  (INTEGER  raayo  <>)  o(  UN5IGNED_L0NGH0RD; 


13.7a.4  Conventional  Names  for  Unsigned  Longwords 

The  following  XD  Ada  declarations  provide  conventional  names  for 
static  subtypes  of  the  predefined  type  UNSIGNED. LONGWORD: 


auktypa 

UNSIGNED. 

1 

la 

UNSIGNED. 

LONGWORO 

0 

2* 

1-1 

auktypa 

UNSIGNED. 

2 

la 

UNSIGNED. 

LONGWORD 

0 

2» 

2-1 

aubtypo 

UNSIGNED. 

3 

la 

UNSIGNED. 

LONGWORO 

rasfB 

0 

2* 

3-1 

aubtypo 

UNSIGNED. 

4 

la 

UNSIGNED. 

LONGWORO 

raaga 

0 

2* 

4-1 

aubtypo 

UNSIGNED. 

S 

la 

UNSIGNED. 

LONGWORD 

raaf* 

0 

2* 

5-1 

aubtypo 

UNSIGNED. 

« 

la 

UNSIGNED. 

LONGWORD 

0 

2* 

6-1 

aubtypo 

UNSIGNED. 

7 

la 

UNSIGNED. 

LONGWORD 

raafB 

0 

2* 

7-1 

aubtypo 

UNSIGNED. 

8 

la 

UNSIGNED. 

LONGWORD 

raaga 

0 

2* 

8-1 

aubtypo 

UNSIGNED. 

9 

la 

UNSIGNED. 

LONGWORD 

raaga 

0 

2* 

9-1 

aubtypo 

UNSIGNED. 

10 

la 

UNSIGNED. 

LONGWORD 

raaga 

0 

2* 

10-1 

aubtypo 

UNSIGNED. 

11 

la 

UNSIGNED. 

LONGWORD 

raaf# 

0 

2* 

11-1 

aubtypo 

UNSIGNED. 

12 

la 

UNSIGNED. 

LONGWORD 

raafa 

0 

2» 

12-1 

aubtypo 

UNSIGNED. 

13 

la 

UNSIGNED. 

LONGWORO 

raaya 

0 

2* 

13-1 

aubtypo 

UNSIGNED. 

14 

la 

UNSIGNED. 

LONGWORD 

raaya 

0 

2* 

14-1 

aubtypo 

UNSIGNED. 

IS 

la 

UNSIGNED. 

LONGWORO 

raaga 

0 

2* 

15-1 

aubtypo 

UNSIGNED. 

16 

la 

UNSIGNED 

LONGWORD 

raafa 

0 

2* 

16-1 

aubtypo 

UNSIGNED. 

17 

la 

UNSIGNBD.LONGNORD 

raafa 

0 

2* 

17-1 

aubtypo 

UNSIGNED. 

18 

lo 

UNSIGNED. 

LONGWORD 

raafa 

0 

2* 

18-1 

aubtypo 

UNSIGNED. 

19 

la 

UNSIGNED. 

LONGWORO 

raafa 

0 

2* 

19-1 

aubtypo 

UNSIGNED. 

20 

Is 

UNSIGNED. 

LONGWORO 

raafa 

0 

2* 

20-1 

aubtypo 

UNSIGNED. 

21 

lo 

UNSIGNED. 

LONGWORO 

raafa 

0 

2* 

21-1 

aubtypo 

UNSIGNED. 

22 

Is 

UNSIGNED. 

LONGWORO 

raafa 

0 

2* 

22-1 

aubtypo 

UNSIGNED. 

23 

la 

UNSIGNED. 

LONGWORD 

raafa 

0 

2» 

23-1 

aubtypo 

UNSIGNED. 

24 

lo 

UNSIGNED. 

LONGWORD 

raafa 

0 

2* 

24-1 

aubtypo 

UNSIGNED. 

25 

lo 

UNSIGNBD.LONGNORD 

raafa 

0 

2« 

25-1 

aubtypo 

UNSIGNED. 

26 

lo 

UNSIGNED. 

.LONGWORD 

raafa 

0 

2* 

26-1 

aubtypo 

UNSIGNED. 

27 

is 

UNSIGNED. 

LONGWORD 

raafa 

0 

2* 

27-1 

aubtypo 

UNSIGNBD.28 

lo 

UNSIGNED. 

LONGWORD 

raafa 

0 

2* 

28-1 

aubtypo 

UNSIGNED.!? 

Is 

UNSIGNED. 

LONGWORD 

raafa 

0 

2* 

29-1 

aubtypo 

UNSIGNED.30 

lo 

UNSIGNED. 

LONGWORD 

raafa 

0 

2* 

30-1 

aubtypo 

UNSIGNED.31 

Is 

UNSIGNED. 

LONGWORD 

raafa 

0 

.  - 

2« 

31-lj 
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13.7.1  Syst«m*Oependent  Named  Numbers 

In  XD  Ada,  the  values  for  system-dependent  named  numbers  are  as 
shown  in  the  following  table. 


Attribute 

MC63020 

MIN.INT 

-2" 

MAXJNT 

2”-l 

MAX.DIGITS 

18 

MAX.MANTISSA 

31 

FINE.DELTA 

1 

o 

IN 

TICK 

162.5  X  10-* 

13.7.2  Representation  Attributes 

The  following  information  supplements  all  of  this  section: 

For  any  object,  program  unit,  label,  or  entry  X: 

X' ADDRESS  Yields  the  address  of  the  first  of  the  storage  ele¬ 

ments  allocated  to  X.  For  a  subprogram,  package, 
task  unit  or  label,  this  value  refers  to  the  machine 
code  associated  with  the  corresponding  body  or 
statement.  For  an  entry  for  which  an  address 
clause  has  been  given,  the  value  refers  to  the  offset 
of  the  interrupt  vector  from  the  vector  base  register. 
The  value  of  this  attribute  is  of  the  type  ADDRESS 
defined  in  the  package  SYSTEM. 

For  an  object  that  is  a  variable,  the  value  is  the  ac¬ 
tual  address  of  the  variable  (which  may  be  statically 
or  dynamically  allocated),  liiis  attribute  forces  a 
variable  to  be  allocated  in  memory  rather  than  in 
a  register,  and  causes  the  variable  to  be  marked  as 
volatile  for  the  duration  of  the  block  statement  or 
body  containing  use  of  the  attribute.  If  the  location 
of  the  variable  is  not  byte-aligned,  the  value  is 
the  address  of  the  lowest  byte  that  contains  the 
variable.  For  an  object  that  is  a  constant,  the  value 
is  the  address  of  the  constant  value  in  memory; 
however,  two  occurrences  of  C'ADDRESS,  where 
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C  denotes  a  constant,  may  or  may  not  yield  the 
same  address  value.  For  an  object  that  is  a  named 
number,  the  value  is  zero  (ADDRESS.ZERO). 

NOTE 

In  the  context  of  these  representation 
attributes,  ADDRESS_ZERO  means  only 
that  no  useful  interpretation  of  a  nonzero 
value  is  currently  supported.  That  is,  its 
use  as  a  result  of  C' ADDRESS  is  subject 
.o  change. 

For  an  access  object,  X.all'ADDRESS  is  the  address 
of  the  designated  object;  X.all'ADDRESS  is  subject 
to  an  ACCESS_CHECK  for  the  designated  object. 
For  a  record  component,  X.C' ADDRESS  is  subject 
to  a  piSCRIMlNANT.CHECK  for  an  object  in 
a  variant  part.  For  an  array  component  or  slice, 
X(I)' ADDRESS  or  X(I1... 12)' ADDRESS  is  subject  to 
an  INDEX_CHECK  for  the  denoted  component  or 
slice. 

For  program  units  that  are  task  units  or  package 
units,  the  value  is  zero  (ADDRESS.ZERO).  For 
program  units  that  are  subprograms,  the  value  is 
the  same  as  the  address  that  would  be  exported. 
(See  Section  13.9a. 1.4  (LRM)  for  information  on 
pragmas  EXPORT.FUNCTION  and  EXPORT 
PROCEDURE). 

For  entries,  the  value  is  zero  (ADDRESS.ZERO). 

For  labels,  the  value  is  the  address  of  the  machine 
code  which  follows  the  label. 

For  any  type  or  subtype  X,  or  for  any  object  X; 

X'SIZE  For  a  type  or  a  subtype,  the  value  is  limited  to 

values  in  the  range  0  ..  MAX.INT;  the  exception 
NUMERlC_ERROR  (see  Section  11.1)  is  raised  for 
values  outside  this  range.  For  an  object  that  is  a 
variable  or  a  constant  in  XD  Ada,  the  value  is  its 
size  in  bits.  For  an  object  that  is  a  named  num¬ 
ber,  the  value  is  zero.  For  a  record  component, 

X.C 'SIZE  is  subject  to  a  DISCRIMINANT.CHECK 
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for  an  object  in  a  variant  part.  For  an  array  compo¬ 
nent  or  slice,  X(I)'SIZE  or  X(I1..I2)'SIZE  is  subject 
to  an  INDEX_CHECK  for  the  denoted  component 
or  slice. 

For  any  type  or  subtype  X; 

X'MACHINE.SIZE  Yields  the  number  of  machine  bits  to  be  allocated 
for  variables  of  the  type  or  subtype.  This  value 
takes  into  account  any  padding  bits  used  by  XD 
Ada  when  allocating  a  variable  on  a  byte  boundary. 
The  value  of  this  attribute  is  of  the  type  umversal_ 
integer. 

The  value  is  always  a  multiple  of  8  (bits).  In  partic¬ 
ular,  for  discrete  types  it  is  8,  16,  or  32.  The  value 
is  limited  to  the  range  O..MAX_INT;  the  exception 
NUMERIC.ERROR  is  raised  for  values  outside  this 
range. 

For  any  object  X: 

X'BIT  Yields  the  bit  offset  within  the  storage  unit  (byte) 

that  contains  the  first  bit  of  the  storage  allocated  for 
the  object.  The  value  of  this  attribute  is  of  the  type 
uniwrsaljnteger.  and  is  always  in  the  range  0..7. 

For  an  object  that  is  a  variable  or  a  constant  al¬ 
located  in  a  register,  the  value  is  zero.  (The  use 
of  this  attribute  does  not  force  the  allocation  of 
a  variable  to  memory.)  For  an  object  that  is  a 
formal  parameter,  this  attribute  applies  either 
to  the  matching  actual  parameter  or  to  a  copy 
of  the  matching  actual  parameter.  For  an  ac¬ 
cess  object,  the  value  is  zero  (in  the  absence  of 
CONSTRAINT.ERROR);  X.all'BIT  is  subject  to 
an  ACCESS.CHECK  for  the  designated  object. 

For  a  record  component,  X.C'BIT  is  subject  to 
a  DISCRIM1NANT_CHECK  for  a  component  in 
a  variant  part.  For  an  array  component  or  slice, 
X(I)'Brr  or  X(I1..I2)'BIT  is  subject  to  an  INDEX. 
CHECK  for  the  denoted  component  or  slice. 
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Th*  following  information  supplements  the  Notes  section: 

The  attribute  X'MACHINE_SIZE  gives  the  size  that  would  be  used  for 
a  variable  of  the  type  or  subtype;  it  does  not  give  the  size  that  may  be 
used  for  a  component  of  that  type  or  subtype. 

The  machine  size  of  a  type  or  subtype  can  be  influenced  by  representa¬ 
tion  clauses,  unlike  the  size  of  a  type  or  subtype,  which  is  independent 
of  representation  clauses.  The  machine  size  of  a  base  type  can  be  less 
than,  equal  to,  or  greater  than  the  size  of  that  same  base  type.  See  the 
XO  Ada  MC68020  Run-Time  Reference  Manual  for  examples  and  additional 
discussion. 


13.7.3  R«presentation  Attributes  of  Real  Types 

The  foUo%ving  information  supplements  paragraphs  3  and  4: 

For  both  fixed-  and  floating-point  types: 

T'MACHINE.ROUNDS  In  XD  Ada  this  value  is  FALSE 

T'MACHINE.OVERFLOWS  In  XD  Ada  this  value  is  FALSE 

The  XD  Ada  values  of  the  other  representation  attributes  for  floating¬ 
point  types  are  dependent  on  the  floating-point  type  and  are  listed  in 
Appendbc  F. 


13.8  Machine  Code  Insertions 

The  following  information ’supplements  paragraph  4: 

XD  Ada  provides  the  package  MACHINE.CODE.  Machine  code  inser¬ 
tions  can  be  expanded  in  line. 

This  predefined  package  and  not  a  user-defined  package  must  be 
named  in  a  with  clause  that  applies  to  the  compilation  unit  in  which  the 
code  statement  occurs. 

The  following  is  an  example  of  MACHINE.CODE  and  the  with  clause 
in  use: 
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--  A  machin*  code  procedure  to  evaluate  the  sine  and  cosine  of 
--  parameter  X,  returning  the  results  in  parameters  Y  and  Z 
—  respectively;  the  procedure  is  to  be  expanded  in  line,  so 
--  it  does  not  require  a  stack  frame  of  its  own: 
wltA  MACHINE_CODB; 

procedure  SI NCOS  1  (  Xi  la  FLOAT; 

Ys  out  FLOAT; 

Zt  out  FLOAT  I  is 
use  MACHINE_COOB; 
bepla  FSINCOS_REG_INST'  ( 

OPCODE  ->  FSINCOS, 

SOURCB_ReGISTBR  ->  FPO, 

SIN_REGISTER  ->  FPl, 

COS~REGISTEH  ->  FP2  ) ; 

ead  SlNCOSl; 

XD  Ada  provides  the  pragma  CALL_SEQUENCE_PROCEDURE  which 
specifies  parameter-passing  mechanisms  for  machine  code  procedures. 
The  pragma  is  defined  in  Appendix  B.  Examples  of  machine  code 
insertion  are  given  in  Section  6.1  of  the  XD  Ada  MC68020  Run-Time 
Reference  Manual.  For  the  specification  of  the  package  MACHINE. 
CODE,  see  Appendix  B  of  the  XD  Ada  MC68020  Run-Time  Reference 
Manual. 


13.9  Interface  to  Other  Languages 

The  following  information  supplements  paragraph  4: 

As  with  VAX  Ada,  use  of  pragma  INTERFACE  in  XD  Ada  is  interpreted 
as  being  equivalent  to  supplying  the  body  of  the  named  subprogram  or 
subprograms.  Therefore,  the  following  rules  apply: 

•  If  a  subprogram  body  is  given  later  for  a  subprogram  named  with 
pragma  INTERFACE,  the  body  is  illegal. 

•  If  pragma  INTERFACE  names  a  subprogram  body,  the  pragma  is 
illegal. 

•  If  a  duplicate  pragma  INTERFACE  is  given,  the  latter  pragma  is 
illegal. 

In  XD  Ada,  pragma  INTERFACE  applies  to  a  renaming  only  if  the 
renaming  occurs  in  the  same  declarative  part  or  package  specification 
as  the  pragma.  The  renamed  subprogram  must  also  occur  in  that  same 
declarative  part  or  package  specification;  renamed  subprograms  that 
occur  outside  the  declarative  part  or  package  specification  are  ignored 
(without  a  warning  diagnostic). 
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In  addition,  XD  Ada  interprets  the  effect  of  pragma  INTERFACE  in  such 
a  way  that  it  accepts  and  ignores  implicit  declarations  of  subprograms 
(such  as  predefined  operators,  derived  subprograms,  attribute  functions, 
and  so  on). 

Dependent  upon  its  use  in  an  XD  Ada  program,  pragma  INTERFACE  is 
interpreted  in  combination  with  one  of  two  XD  Ada  import  subprogram 
pragmas:  IMPORT.FUNCTION  or  IMPORT.PROCEDURE.  These 
pragmas  are  described  in  Section  I3.9a.l. 

The  language  name  is  ignored,  and  so  may  be  any  identifier  that 
suggests  the  language,  source,  or  nature  of  the  imported  subprogram. 

If  pragma  INTERFACE  is  used  without  one  of  these  import  pragmas,  a 
default  interpretation  is  used,  as  follows: 

•  If  the  subprogram  name  applies  to  a  single  subprogram,  then  a 
default  import  pragma  is  assumed  as  follows: 

For  a  function,  the  default  is  as  follows: 

prae««  tMPORT_ruNCTIOM  ( function_designator) ; 

For  a  procedure,  the  default  is  as  follows: 

prM«M  tMPORT_PROCEDURe  (procedur«_identif ier ) ; 

*  If  the  subprogram  name  applies  to  two  or  more  subprograms,  the 
pragma  applies  to  all  of  them.  However,  a  warning  is  given  if  the 
appropriate  XD  Ada  import  pragmas  are  not  given  for  all  of  the 
subprograms. 

Whether  or  not  pragma  INTERFACE  is  used  with  an  import  pragma,  the 
subprogram  name  must  be  an  identifier,  or  a  string  literal  that  denotes 
an  operator  symbol.  In  the  follovring  example,  pragma  INTERFACE 
specifies  that  the  indicated  routines  SQRT  and  EXP  are  to  be  imported 
and  used  as  bodies  for  the  XD  Ada  functions  SQRT  and  EXP  in  package 
FORT.UB; 

rORT.LIB  ia 

faaetloa  SQRTIX  i  FLOAT)  ratara  FLOAT; 
faaatlaa  EXP(X  i  FLOAT)  ratura  FLOAT; 
priaata 

pra«M  INTERFACE)  FORTRAN,  SQRT); 

^ra«M  INTERFACE) FORTRAN.  EXP); 
aa4  FORT.LIB; 
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Th«  following  information  supplements  paragraph  5: 

In  XD  Ada,  the  example  package  FORT. LIB  is  interpreted  as  follows: 
pragma  INTERFACE  specifies  that  the  indicated  routines  SQRT  and 
EXP  are  to  be  imported  and  used  as  bodies  for  the  Ada  functions  SQRT 
and  EXP  in  package  FORT_LIB. 

p«eka««  CHOOSe_R  la 

pracadura  pjx  s  INTEGER); 
praea4ura  P(X  i  FLOAT); 

prlaata 

peacaeura  R(X  i  FLOAT)  raaaaas  P; 
prapaa  INTERFACE (ASSEMBLER,  R); 
aa4  CHOOSe.R; 

In  this  example,  pragma  INTERFACE  indicates  that  the  body  for  the 
second  procedure  P  is  to  be  imported  as  routine  R. 

The  follosving  information  supplements  the  Notes  section: 

The  meaning  of  the  subprogram  name  is  determined  as  for  any  name 
(see  Section  8.3  (LRM)),  except  that  the  name  can  denote  more  than  one 
subprogram.  Thus,  in  the  following  declaration  the  pragma  INTERFACE 
applies  to  the  first  two  procedures;  it  does  not  apply  to  the  third 
because  the  declaration  is  not  visible  at  the  place  of  the  pragma. 

pr««W«r«  P  (Bt  BOOLEAN); 
pr«c«4ar«  P  (It  INTEGER); 
prapM  INTERFACE  (ASSEMBLER,  P); 
pr«c«4«r«  P  (Ft  FLOAT); 

This  same  interpretation  is  made  for  pragmas  used  to  import  and  export 
subprograms  (see  Section  13.9a.  1). 

If  pragma  INTERFACE  and  pragma  INLINE  are  used  together,  the 
pragma  INLINE  is  ignored  regardless  of  the  order  in  which  the  two 
pragmas  appear. 

Refer  to  Chapter  3  of  the  XO  Acin  MC68020  Run-Time  Reference  Manual 
for  subprogram  calling  conventions  and  run-time  organisation,  while 
Chapter  6  of  the  same  manual  describes  low-level  interfaces  and  assem¬ 
bly  language  modules. 
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13.9a  XD  Ada  Import  and  Export  Pragmas 

XD  Ada  provides  import  and  export  pragmas  designed  specifi¬ 
cally  for  constructing  programs  composed  of  both  Ada  and  non- 
Ada  entities.  The  import  pragmas  allow  an  Ada  program  to  refer 
to  entities  written  in  another  language;  the  export  pragmas  make 
Ada  entities  available  to  programs  written  in  other  languages. 

The  names  of  the  pragmas  indicate  the  kind  of  entity  involved: 
IMPORT.FUNCTION  and  EXPORT  FUNCTION  apply  to  nongeneric 
functions;  IMPORT.PROCEDURE  and  EXPORT.PROCEDURE  apply  to 
nongeneric  procedures;  IMPORT  OBJECT  and  EXPORT  OBJECT  apply 
to  objects;  and  IMPORT.EXCEPTION  and  EXPORT.EXCEPTION  apply 
to  exceptions.  These  pragmas  are  described  in  this  section,  summarized 
in  Annex  B,  and  listed  in  Appendix  F. 

All  the  XD  Ada  import  and  export  pragmas  have  the  following  form: 

prafM  import_export_pra9ma_nafli* 

( lnt«rnal_naina  [,  external_de8ignator ) 

[,  pragffla_ap«cific_opcions ) ) ; 

linport_€xport_pragma_name 

BXPORT_BXCHPTION  |  EXPORT_FUNCTION 
I  BXPORT~OBJBCT  j  BXPORt'pROCBDURB 
I  IMP0RT~BXCBPT10N  j  IMPORT~FUNCTICN 

1  import'objbct  I  import“procbdurb 

intarnal_nam*  is-  [INTERNAL  «>)  9imple_naine 

I  (INTERNAL  “>1  oparator_9ymbol  --  Can  ba  used  only  for 

—  IMPORT, FUNCTION 

axtarnal_daal9nator  ti-  (EXTERNAL  •>)  external_9ymbol 

extarnai_symbol  u«  identifier  (  strin9_literal 

The  internal  name  can  be  an  Ada  simple  name,  or,  if  the  declared  entity 
is  a  function,  the  internal  name  can  be  a  string  literal  that  denotes  an 
operator  symbol.  A  subprogram  to  be  imported  or  exported  must  be 
identified  by  its  internal  name  and  parameter  types;  and,  in  the  case  of 
a  function,  by  the  result  t)tpe  (see  Section  13. 9a. 1.1). 

The  external  designator  determines  a  symbol  that  is  referenced  or 
declared  in  the  linker  object  module.  If  an  identifier  is  given,  the 
identifier  is  used.  If  a  string  literal  is  given,  the  value  of  the  string  is 
used.  The  value  of  a  string  literal  must  be  a  symbol  that  is  acceptable 
to  the  XD  Ada  Builder;  it  need  not  be  valid  as  an  Ada  identifier.  (For 
example,  the  dollar  character  ($)  can  be  used.)  If  no  external  designator 
is  given,  the  internal  name  is  used  as  the  external  designator.  If  the 
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external  designator  (explicit  or  default)  is  longer  than  12  characters,  the 
import  or  export  pragma  is  ignored. 

Pragma-specific  options  are  described  in  the  individual  pragma  sections 
that  follow. 

The  XD  Ada  import  and  export  pragmas  are  only  allowed  at  the  place 
of  a  declarative  item,  and  must  apply  to  an  entity  declared  by  an  earlier 
declarative  item  of  the  same  declarative  part  or  package  specification. 
At  most  one  import  or  export  pragma  is  allowed  for  any  given  entity;  in 
the  case  of  multiple  overloaded  subprograms,  this  rule  applies  to  each 
subprogram  independently. 

Additional  placement  and  usage  rules  apply  for  particular  pragmas  as 
described  in  the  following  sections. 

Not*: 

Armment  associations  for  XD  Ada  import  and  export  pragmas  can  be 
either  positional  or  named.  With  positional  association,  the  arguments 
are  interpreted  in  the  order  in  which  they  appear  in  the  S3mtax  defini¬ 
tion.  The  rules  for  the  mixing  of  positional  and  named  association  are 
the  same  as  those  that  apply  to  subprograms  (see  Section  6.4  (LRM)). 

A  pragma  for  an  entity  declared  in  a  package  specification  must  not  be 
given  in  the  package  body.  (A  pragma  for  an  entity  given  in  the  visible 
part  of  a  package  specification  can,  however,  be  given  in  either  the 
visible  or  private  part  of  the  specification.) 

No  checking  is  provided  to  ensure  that  exported  symbols  do  not  con¬ 
flict  with  each  other  or  with  other  global  symbols;  such  checking  is 
performed  by  the  XD  Ada  Builder. 


'^3.9a.1  Importing  and  Exporting  Subprograms 

XD  Ada  provides  a  series  of  pragmas  that  make  it  possible  to  call 
nongeneric  subprograms  in  a  mixed-language  programming  environ¬ 
ment.  The  IMPORT. FUNCTION  and  IMPORT.PROCEDURE  pragmas 
specify  that  the  body  of  the  subprogram  associated  with  an  Ada  sub¬ 
program  specification  is  to  be  provided  from  assembly  language. 
Pragma  UNTTERFACE  must  precede  one  of  these  import  pragmas  (see 
Section  13.9).  The  EXPORT.FUNCTTON  and  EXPORT.PROCEDURE 
pragmas  allow  an  Ada  procedure  or  function  to  be  called  from  assem¬ 
bly  language.  The  pragmas  support  parameter  passing  by  means  of 
registers. 
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13.9a. 1.1  Importing  Subprograms 

XD  Ada  provides  two  pragmas  for  importing  subprograms: 
IMPORT.FUNCTION  and  IMPORT.PROCEDURE.  These  pragmas 
allow  the  import  of  the  kind  of  subprograms  indicated. 

The  pragmas  for  importing  subprograms  have  the  following  form: 

rrafU  tMli»ORT_rUNCTION  I  IMPORT_PROCEDURE 

(I  INTERNAL  •>!  lntarnal_naine 
[(  (EXTERNAL  «>)  extarnal_desiqnator  1 
(.  [ PARAMETER_TYPBS  •>]  (  parameter_types  )  ) 

(,  iRBSOLT_TYPB  ->]  type  mark  )  —  FUNCTION  only 

(,  (MBCHANISH  ->|  mechanism  ] 

(,  ( RBSULT_MBCKANISM  »>)  mechanism_spec  1  FUNCTION  only 
it  (PRBSBRVBO_RBaiSTBRS  •>  )  (  reqiacers  )  | 

)> 

paranatar_typea  tt~ 

aall  I  typa_marlt  {,  type_mark> 

mechanism  it> 

machanlsm_spec  |  (  mechanism_spec  {,  mechanism_spac)  ) 
mochanlsm_spec  ii» 

machanism_name  (  (  (REGISTER  •>  ]  reqister_nama  )  | 
mechanlsm_namo  t:> 

value"  I 

REFERENCE  j  BIT, REFERENCE  | 

OOPB_VECTOR  I  BIT,DOPB_VECTOR 

reqiatera  tt“ 

aali  I  registar_name  (,  re<3ister_nama  ) 

Functions  must  be  identified  by  their  internal  names  and  parameter 
and  result  types.  The  parameter  and  result  types  can  be  omitted  only  if 
there  is  exactly  one  function  of  that  name  in  the  same  declarative  part  or 
package  specification.  Otherwise,  both  the  parameter  and  result  types 
must  be  specified. 

Procedures  must  be  identified  by  their  internal  names  and  parameter 
types.  The  parameter  types  can  be  omitted  only  if  there  is  exactly 
one  procedure  of  that  name  in  the  same  declarative  part  or  package 
specification.  Otherwise,  the  parameter  types  must  be  specified. 

The  external  designator  denotes  an  XD  Ada  Builder  global  symbol  that 
is  associated  with  the  external  subprogram.  If  no  external  designator  is 
given,  the  internal  name  is  used  as  the  global  symbol. 
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The  parameter  types  option  specifies  a  series  of  one  or  more  type 
marks  (type  or  subtype  names),  not  parameter  names.  Each  type  mark 
is  positionally  associated  with  a  formal  parameter  in  the  subprogram's 
declaration.  The  absence  of  parameters  must  be  indicated  by  the 
reserved  word  null. 


The  result  type  option  is  used  only  for  functions;  it  specifies  the  type  or 
subtype  of  the  function  result. 


The  mechanism  option  specifies  how  the  imported  subprogram  expects 
its  parameters  to  be  passed  (for  example,  by  value,  by  reference  or 
by  descriptor).  The  calling  program  (namely  the  XD  Ada  program) 
is  responsible  for  ensuring  that  parameters  are  passed  in  the  form 
required  by  the  external  routine. 


Mechanism  names  are  described  as  follows.  Within  these  definitions, 
the  term  bit  string  means  any  one-dimensional  array  of  a  discrete  type 
whose  components  occupy  successive  single  bits.  The  term  simple 
record  type  means  a  record  type  that  does  not  have  a  variant  part  and  in 
which  any  constraint  for  each  component  and  subcomponent  is  static. 

A  simple  record  subtype  is  a  simple  record  type  or  a  static  constrained 
subtype  of  a  record  type  (with  discriminants)  in  which  any  constraint  for 
each  component  and  subcomponent  of  the  record  type  is  static. 


VALUE 


REFERENCE 
DOPE.  VECTOR 


Specifies  that  the  immediate  value  of  the  actual 
parameter  is  passed.  Values  of  scalars,  access 
types,  address  types  and  private  types  whose 
full  type  is  either  a  scalar,  an  access  type  or  an 
address  type  can  be  passed  by  VALUE.  If  the 
value  is  a  private  type,  the  pragma  must  occur 
after  the  full  declaration  of  the  private  type.  Bit 
strings  can  also  be  passed  by  VALUE. 

Specifies  that  the  address  of  the  value  of  the 
actual  parameter  is  passed.  This  mechanism  can 
be  used  for  parameters  of  any  type. 

Specifies  that  the  address  of  the  DOPE. VECTOR 
is  passed,  a  32-bit  pointer  to  an  object,  taking 
the  form  described  in  Section  2.1.4  of  the  XD 
Ada  MC68020  Run-Time  Reference  Manual. 


BIT.DOPE. VECTOR  Specifies  that  the  address  of  the  BIT. DOPE. 

VECTOR  is  passed,  a  32-bit  pointer  to  an  object, 
taking  the  form  described  in  Section  2.1.4  of  the 
XD  Ada  MC68020  Run-Time  Reference  Manual. 
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If  the  first  form  of  the  mechanism  option  is  given  (a  single  mechanism 
name  without  parentheses),  all  parameters  are  passed  using  that  mech¬ 
anism.  If  the  second  form  is  given  (a  series  of  mechanism  names  in 
parentheses  and  separated  by  commas),  each  mechanism  name  de¬ 
termines  how  the  parameter  in  the  same  position  in  the  subprogram 
specification  will  be  passed.  With  the  second  form,  each  parameter 
name  must  have  an  associated  mechanism  name. 

The  result  mechanism  option  is  used  only  for  functions;  it  specifies 
the  parameter-passing  mechanism  for  passing  the  result  type,  and 
optionally,  a  specific  register  used  to  pass  the  result. 

The  preserved  registers  option  gives  a  list  of  hardware  registers  which 
are  not  altered  by  the  procedure  or  function.  If  this  option  is  omitted  it 
implies  that  no  registers  are  preserved. 

In  addition  to  the  rules  given  in  Section  13.9a.  the  rules  for  importing 
subprograms  are  as  follows: 

•  If  an  import  pragma  is  given  for  a  subprogram  specification,  pragma 
INTERFACE  (see  Section  13.9)  must  also  be  given  for  the  subpro¬ 
gram  earlier  in  the  same  declarative  part  or  package  specification. 
The  use  of  pragma  INTERFACE  implies  that  a  corresponding  body 
is  not  given. 

•  If  a  subprogram  has  been  declared  as  a  compilation  unit,  the 
pragnui  is  only  allowed  after  the  subprogram  declaration  and  before 
any  subsequent  compilation  unit. 

•  These  pragmas  can  be  used  for  subprograms  declared  with  a  re¬ 
naming  declaration.  The  internal  name  must  be  a  simple  name,  and 
the  returning  declaration  must  occur  in  the  same  declarative  part 
or  package  specification  as  the  pragma.  The  renamed  subprogram 
must  also  occur  in  that  same  declarative  part  or  package  specifica¬ 
tion.  Renamed  subprograms  that  occur  outside  the  declarative  part 
or  package  specification  are  ignored  (without  a  warning  diagnostic). 

•  None  of  these  pragmas  can  be  used  for  a  generic  subprogram  or 
a  generic  subprogram  instantiation.  In  particular,  they  cannot  be 
used  for  a  subprogram  that  is  declared  by  a  generic  instantiation  of 
a  predefined  subprogram  (such  as  UNCHECKED.CONVERSION). 
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Examples: 

In  Ihis  example,  the  pragma  INTERFACE  identifies  SQRT  as  an  external 
subprogram;  the  language  name  argument  ASSEMBLER  has  no  effect. 
The  pragma  lMPORT_FUNCTlON  uses  positional  notation  to  specify 
arguments  for  importing  the  declared  function  SQRT.  The  pragma  form 
indicates  that  the  internal  name  is  SQRT,  and  the  external  designator  is 
'MTHSSQRT*.  The  parameter  is  of  type  FLOAT,  and  is  passed  in  FPl; 
the  result  is  of  type  FLOAT,  and  it  is  returned  in  FP2. 


(•■etloa  SQRT  (X  t  FLOAT  t  ratura  FLOAT; 
erafsa  INTCRFACe  (ASSEMBLER,  SQRT); 

VrafM  IHFORT.FUNCTION 

(iORT,  •MTHSSQRT*.  (FLOAT), 
FLOAT,  (VALUe(FRl)),  VALUB(FP2( 
): 


The  next  example  shows  an  alternative  way  of  importing  the  declared 
function  SQRT  using  named  notation.  In  this  case,  the  parameter  is 
passed  in  FP5,  and  the  result  is  returned  in  FP4;  the  registers  which  are 
preserved  by  the  called  function  are  also  specified. 


faactiaa  SQRT  (X  i  LONG_FLOAT  |  ratura  LOHG_FLOAT: 

prafu 
pca«M 


INTERFACE  (ASSEMBLER,  SQRT); 
IMPORT  FUNCTION  ( INTERNAL 


PARAMETER_TYPES 
RESOLT_TYPE 
MECHANISM 
RESULT.MECHAN I SN 
EXTERNAL 

PRESERVED  REGISTERS 


•> 

•> 

•> 

■> 

•> 

•> 

■> 


(DO, 

AO, 


Dl, 

Al, 


D2, 

A2, 


SQRT, 

(LONG_ FLOAT), 
LONG_FLOAT , 
(VALUE) FP5) ) . 
VALUE) rP4 ) , 
•MTHSDSQRT*, 


D3, 

A3, 


D4, 

A4, 


D6, 


D7, 


FPO,  FPl,  FP2,  FP3, 


D5, 

AS, 

FPS ,  FP6 ) ) ; 


If  the  previous  example  is  combined  with  the  code  in  the  first  example 
(that  is,  with  only  one  occurrence  of  pragma  INTERFACE),  the  result  is 
an  overloading  of  SQRT: 


13.Qa.1.1  importing  Subprograms 
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fuaetlea  SQRT  (X  i  LCNG_FLOAT  »  ratura  LC'NG_FLOAT; 
faaetloa  SQRT  (X  s  FLOAT  )  ratura  FLOAT; 
rrafoa  INTERFACE  (ASSEMBLER,  SQRT); 
prayaa  IMPORT_FUNCTION  (SQRT, 

-MTHSSQHT*, 

(FLOAT), 

FLOAT, 

(VALUE(FPl) ), 

VALUE) FP2 ) ); 

prapaa  IMPORT_rUNCTION  (INTERNAL  ->  SQRT, 

PARAMETER_TYPES  ->  ( LONG_ FLOAT ) , 

RESULT_TYPE  ->  LONG_FLOAT, 

MECHANISM  ->  ( VALUE ( FP5 ) ) , 

RESULT_MECHANISM  ->  VALUE) FP4 ) , 

EXTERNAL  ->  •MTHSDSQRT*, 

PHESERVED_RBGtSTBRS  -> 

(00,  01,  02,  03,  04,  05,  06,  07, 

AO,  Al,  A2,  A3,  A4,  A5, 

FPO,  FPl,  FP2,  FP3,  FPS,  FP6 ) ) ; 

The  next  example  shows  the  use  of  renaming  with  an  imported  pro¬ 
cedure  (it  is  assumed  that  these  declarations  occur  in  a  declarative 
part  or  package  specification).  Note  that  the  renaming  causes  the  im¬ 
ported  ASSEMBLER  procedure  to  be  used  in  calls  to  both  procedures 
CHANGE  and  EXCHANGE.  Also  note  that  because  no  external  desig¬ 
nator  is  specified,  the  builder  global  symbol  associated  with  the  external 
subprogram  is  EXCHANGE,  and  because  no  parameter  mechanisms 
are  specified,  the  compiler's  defaults  will  apply  in  calls  to  CHANGE  or 
EXCHANGE. 

pr«C«aur«  CHANGE  (X,Y  t  INTEGER); 

prucudura  EXCHANGE  (X,Y  <  INTEGER)  raaaaas  CHANGE; 

pra«M  INTERFACE  (ASSEMBLER,  EXCHANGE); 

pra«M  IMPORT.PROCEDURE  (INTERNAL  •>  EXCHANGE, 

PARAMETER_TYPBS  »>  ( INTEGER, INTEGER) ) ; 


I3.9t.1.2  Exporting  Subprogram* 

XD  Ada  provides  two  pragmas  for  exporting  subprograms: 
EXPORT.FUNCTION  and  EXPORT.PROCEDURE.  Both  export  prag¬ 
mas  establish  an  external  name  for  a  subprogram  and  make  the  name 
available  to  the  XD  Ada  Builder  as  a  global  symbol,  so  that  the  subpro¬ 
gram  can  be  called  by  an  assembly  language  module. 

The  EXPORT.FUNCTION  and  EXPORT. PROCEDURE  pragmas  allow 
the  export  of  the  kind  of  subprograms  indicated. 
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The  pragmas  for  exporting  subprograms  have  the  following  form; 

pragma  BXPORT_FUNCTrON  |  EXPORT_PBOCEDURB 

(  (  INTERNAL  “>|  internal_naiiie 

(,  (EXTERNAL  •>)  external_de9 ignator  ) 

[,  ( PARAMETER_TYPES  •>(  (  parameter_types  )  ) 

(,  iRESULT_TYPE  ->(  type_marX  (  —  FUNCTION  only 

[,  (MECHANISM  •> |  mechanism  ] 

(,  (RESULT_MECHANISM  •>]  mechanism  spec  )  —  FUNCTION  only 

)I 

parametar  typea  tt» 

sail  T  type_marlc  (,  type_mark> 

mechanism  tta 

meehanlaffl_spee  |  (  mechaniam_spac  {,  mechanism_spec>  ) 
mechanlam_apec  (>• 

mechaniam_name  (  (  (REGISTER  •>  |  regiscer_name  )  ] 
mechanisffl_naflie  ti> 

value"  I 

REFERENCE  |  aiT_REFERBNCE  | 

OOPB_VBCTOR  I  81T_OOPB_VECTOR 

registara  tt- 

sail  I  regiater_name  (,  registar_nama  > 

paramatar_typaa  t>> 

sail  I  type_mark  {,  typa_mark) 

Functions  must  be  identified  by  their  internal  names  and  parameter 
and  result  types.  The  parameter  and  result  types  can  be  omitted  only  if 
there  is  exactly  one  function  of  that  name  in  the  same  declarative  part  or 
package  specification.  Otherwise,  both  the  parameter  and  result  types 
must  be  specified. 

Procedures  must  be  identified  by  their  internal  names  and  parameter 
types.  The  parameter  types  can  be  omitted  only  if  there  is  exactly 
one  procedure  of  that  name  in  the  same  declarative  part  or  package 
specification.  Otherwise,  the  parameter  types  must  be  specified. 

The  external  designator  denotes  an  XD  Ada  Builder  global  symbol 
that  is  associated  with  the  external  subprogram.  If  no  external  name  is 
given,  the  internal  name  is  used  as  the  global  symbol. 

The  parameter  types  option  specifies  a  series  of  one  or  more  type 
marks  (type  or  subtype  names),  not  parameter  names.  Each  type  mark 
is  positionally  associated  with  a  formal  parameter  in  the  subprogram's 
declaration.  The  absence  of  parameters  must  be  indicated  by  the 
reserved  word  null. 
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The  result  type  option  is  used  only  for  functions;  it  specifies  the  type  or 
subtype  of  the  function  result. 

The  mechanism  option  specifies  how  the  imported  subprogram  expects 
its  parameters  to  be  passed  (for  example,  by  value,  by  reference  or 
by  descriptor).  The  calling  program  (namely  the  XD  Ada  program) 
is  responsible  for  ensuring  that  parameters  are  passed  in  the  form 
required  by  the  external  routine.  Mechanism  options  and  possible 
values  for  mechanism  names  and  class  names  are  described  in  Section 
13.9a.l.l. 

If  the  first  form  of  the  mechanism  option  is  given  (a  single  mechanism 
name  without  parentheses),  all  parameters  are  passed  using  that  mech¬ 
anism.  If  the  second  form  is  given  (a  series  of  mechanism  names  in 
parentheses  and  separated  by  commas),  each  mechanism  name  de¬ 
termines  how  the  parameter  in  the  same  position  in  the  subprogram 
specification  will  be  passed.  With  the  second  form,  each  parameter 
name  must  have  an  associated  mechanism  name. 

The  result  mechanism  option  is  used  only  for  functions;  it  specifies 
the  parameter-passing  mechanism  for  passing  the  result  type,  and 
optionally,  a  specific  register  used  to  pass  the  result. 

In  addition  to  the  rules  given  in  Section  13. 9a,  the  rules  for  exporting 
subprograms  are  as  follows; 

•  An  exported  subprogram  must  be  a  library  unit  or  be  declared  in 
the  outermost  declarative  part  of  a  library  package.  Thus,  pragmas 
for  exporting  subprograms  are  allowed  only  in  the  following  cases: 

—  For  a  subprogram  specification  or  a  subprogram  body  that  is  a 
library  unit 

—  For  a  subprogram  specification  that  is  declared  in  the  outermost 
declarations  of  a  package  specification  or  a  package  body  that  is 
a  library  unit 

—  For  a  subprogram  body  that  is  declared  in  the  outermost  decla¬ 
rations  of  a  package  body  that  is  a  library  unit 

Consequently,  an  export  pragma  for  a  subprogram  body  is  allowed 
orJy  if  either  the  body  does  not  have  a  corresponding  specification, 
or  the  specification  and  body  occur  in  the  same  declarative  part. 

This  set  of  rules  implies  that  an  EXPORT_FUNCTION  or 
EXP0RT_PR0CEDURE  pragma  cannot  be  given  for  a  generic  li¬ 
brary  subprogram,  nor  can  one  be  given  for  a  subprogram  declared 
in  a  generic  library  package.  However,  either  of  these  pragmas 
can  be  given  for  a  subprogram  resulting  from  the  instantiation  of 
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a  generic  subprogram,  provided  that  the  instantiation  othenvise 
satisfies  this  set  of  rules. 

•  In  the  case  of  a  subprogram  declared  as  a  compilation  unit,  the 
pragma  is  only  allowed  after  the  subprogram  declaration  and  before 
any  subsequent  compilation  unit. 

•  Neither  of  these  pragmas  can  be  used  for  a  subprogram  that  is 
declared  with  a  renaming  declaration. 

•  Neither  of  these  pragmas  can  be  used  for  a  subprogram  that  is 
declared  by  a  generic  instantiation  of  a  built-in  library  subprogram 
(such  as  UNCHECKED.CONVERSION). 

Exampitt: 

The  following  example  shows  an  export  pragma  that  causes  the  Ada 
procedure  PROC  to  be  exported  for  use  in  an  assembly  language 
module.  The  name  PROC  is  declared  as  an  XD  Ada  Builder  global 
symbol. 

proc«auca  PROC  (Y  :  INTEGER); 

Rraffsa  EXPORT_PROCEDURe  (PROC); 

The  next  example  shows  an  Ada  function  being  called  from  an  assembly 
language  module; 

fnaetiaa  MULTIPLY  ( Y  i  la  INTEGER)  ratura  INTEGER  la 


bafla 

ratara  Y  *  10; 

aa4) 

prataa 

EXPORT  FUNCTION  (  INTERNAL  ->  MULTIPLY, 

PARAMETER  TYPES 

•>  (INTEGER), 

RESULT_TYPE 

->  INTEGER  ) ; 

Era«wa 

CALL_SEQUBNCB_rUNCTIOM  ( 

UNIT 

->  MULTIPLY, 

PARAMETER  TYPES 

»>  (INTEGER), 

MECHANISM 

->  (VALUE (DO)) 

RESOLT_MECHANI SM 

->  VALUE) DO)  ); 

TITLE  ■MCS8020  Calling  Ada* 
MODULE  ‘CALL  ADA* 


XDEf  CALL_AOX 
XRBF  MULTIPLY 

OS  EG 

A  BLXB  4  I  An  INTEGER 

PSEG 
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CALL  ADA 


MOVE . L 

*l,A  !  A  :•  1; 

MOVE . L 

A,  DO 

JSR 

MULTIPLY. L 

MOVE.L 

RTS 

DO, A  !  A  ;•  MULTIPLE' 

END 

13.9a. 2  Importing  and  Exporting  Objects 

XD  Ada  provides  two  pragmas  for  importing  and  exporting  objects: 
IMPORT.OBJECT  and  EXPORT.OBJECT.  The  IMPORT.OBJECT 
pragma  references  storage  declared  in  an  assembly  language  module. 
iT\e  EXPORT.OBJECT  pragma  allows  an  assembly  language  module  to 
refer  to  the  storage  allocated  for  an  Ada  object. 

In  addition  to  the  rules  given  in  Section  13.9a,  the  rules  for  importing 
and  exporting  objects  are  as  follows; 

•  The  object  to  be  imported  or  exported  must  be  a  variable  declared 
by  an  object  declaration  at  the  outermost  level  of  a  library  package 
specification  or  body. 

•  The  subtype  indication  of  an  object  to  be  imported  or  exported  must 
denote  one  of  the  following; 

—  A  scalar  type  or  subtype. 

—  An  array  subtype  with  static  index  constraints  whose  component 
size  is  static. 

—  A  record  type  or  subtype  that  does  not  have  a  variant  part  and 
in  which  any  constraint  for  each  component  and  subcomponent 
is  static  (a  simple  record  type  or  subtype). 

•  Import  and  export  pragmas  are  not  allowed  for  objects  declared 
with  a  renaming  declaration. 

•  Import  and  export  pragmas  for  objects  are  not  allowed  in  a  generic 
unit. 
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Notes: 


Objects  of  private  or  limited  private  types  cannot  be  imported  or 
exported  outside  the  package  that  declares  the  (limited)  private  type. 
They  can  be  imported  or  exported  inside  the  body  of  the  package  where 
the  type  is  declared  (that  is.  ivhere  the  full  type  is  known). 

The  XD  Ada  pragmas  for  importing  or  exporting  objects  can  precede  or 
follow  a  pragma  VOLATILE  for  the  same  objects  (see  Section  9.11). 

Address  clauses  are  not  allowed  in  combination  with  any  of  the  XD  Ada 
pragmas  for  importing  or  exporting  objects.  If  used  in  such  cases,  the 
pragnra  involved  is  ignored  (see  Section  13.5). 


13.9a.2.1  Importing  Objactt 

The  XD  Ada  lMPORT_OBJECT  pragma  specifies  that  the  storage  allo¬ 
cated  for  the  object  (when  the  assembly  language  moi'ule  is  compiled) 
be  made  known  to  the  calling  Ada  program  by  an  externally-defined  XD 
Ada  Builder  global  symbol. 

Pragma  IMPORT.OBJECT  has  the  following  form: 

fra«aa  IMPORT_OBJECT 

(  internal_naina  (,  external_desiqnator  ) ) 

The  internal  name  is  the  object  identifier.  The  external  designator 
denotes  an  XD  Ada  Builder  global  symbol  that  is  associated  with  the 
external  object.  If  no  external  designator  is  given,  the  internal  name  is 
used  as  the  global  symbol. 

Because  it  is  not  created  by  an  Ada  elaboration,  an  imported  object 
cannot  have  an  initial  value.  Specifically,  this  restriction  means  that  the 
object  to  be  imported: 

•  Cannot  be  a  constant  (have  an  explicit  initial  value). 

•  Cannot  be  an  access  type  (which  has  a  default  initial  value  of  null). 

•  Cannot  be  a  record  type  that  has  discriminants  (which  are  always 
initialized)  or  components  with  default  initial  expressions. 

•  Caruiot  be  an  object  of  a  task  type. 
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Example: 

PIDl  INTEGER; 

prafaa  IMPORT_OBJECT  (PIO,  'PROCESSS ID* ( ; 

In  this  example,  the  variable  PID  refers  to  the  externally-defined  symbol 
PROCESSSID. 

Alternatively,  this  example  can  be  written  in  named  notation  as  follows; 

PID  I  INTEGER; 

pra«aa  IMPORT_OBJECT  (INTERNAL  ->  PID, 

EXTERNAL  ->  "PROCESSSID-); 


13.9a.2.2  Exporting  Obiacta 

The  XD  Ada  pragma  EXPORT_OBJECT  specifies  that  the  storage  al¬ 
located  for  the  object  (when  the  Ada  program  is  compiled)  be  made 
known  to  assembly  language  modules  by  an  XD  Ada  Builder  global 
symbol. 

Pragma  EXPORT_OBJECT  has  the  following  form: 

pra««a  expORT_OBJECT 

( l.ntarnal_nania  J,  external_desiqnator ) ) 

The  internal  name  is  the  object  identifier.  The  external  designator 
denotes  an  XD  Ada  Builder  global  symbol  that  is  associated  with  the 
external  object.  If  no  external  designator  is  given,  the  internal  name  is 
used  as  the  global  symbol. 

Examplo: 

PIOs  INTEGER; 

prafM  EXPORT.OBJECT  (PID,  "PROCESSSID"); 

Alternatively,  this  example  can  be  written  in  named  notation: 

PIO I  INTEGER! 

pvapM  EXPORT_OBJECT  (INTERNAL  ->  PID, 

EXTERNAL  ->  "PROCESSSID"); 
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13. 9a. 3  Importing  and  Exporting  Exceptions 

XD  Ada  provides  the  IMPORT.EXCEPTION  and  EXPORT.EXCEPTION 
pragmas  for  importing  and  exporting  exceptions.  The  pragma  IMPORT, 
EXCEPTION  allows  non-Ada  exceptions  to  be  used  in  Ada  programs; 
the  pragma  EXPORT_EXCEPTION  allows  Ada  exceptions  to  be  used  by 
foreign  units. 

The  rules  for  importing  and  exporting  exceptions  are  given  in  Section 
13.9a. 

Note: 

A  pragma  for  an  exception  that  is  declared  in  a  package  specification  is 
not  allowed  in  the  package  body. 


13.9a.3.1  Importing  Exceptions 

The  XD  Ada  IMPORT.EXCEPTION  pragma  is  provided  for  compatibil¬ 
ity  with  VAX  Ada.  This  pragma  specifies  that  the  exception  associated 
with  an  exception  declaration  in  an  Ada  program  be  defined  externally 
in  non-Ada  code. 

In  XD  Ada  pragma  IMPORT, EXCEPTION  has  the  following  form: 

fra«M  IMPORT,eXCEPTtON 

( internal, name  (,  external,desiqnator ) 

( ,  ( FORM  -> 1  ADA  II; 

The  internal  name  must  be  an  Ada  identifier  that  denotes  a  declared 
exception.  The  external  designator  denotes  an  XD  Ada  Builder  global 
symbol  to  be  used  to  refer  to  the  exception.  If  no  external  name  is 
given,  the  internal  name  is  used  as  the  global  symbol. 

For  compatibility  with  VAX  Ada,  the  form  option  indicates  that  an  Ada 
exception  is  being  imported.  If  omitted,  this  defaults  to  ADA. 

The  external  designator  refers  to  an  address  that  identifies  the  excep¬ 
tion. 

The  VAX  Ada  version  of  this  pragma  supports  an  alternative  form 
(VMS),  and  a  code  option  in  addition  to  the  XD  Ada  arguments.  If 
either  of  these  unsupported  arguments  is  specified,  the  compiler  ignores 
the  pragma  and  issues  a  warning  message. 
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13.9a. 3. 2  Exporting  Exceptions 

The  XD  Ada  EXPORT_EXCEPTION  pragma  allows  Ada  exceptions  to 
be  visible  outside  the  XD  Ada  program,  so  that  they  can  be  raised  and 
handled  by  programs  written  in  XD  Ada  MC68020  assembly  language. 
This  pragma  establishes  an  external  name  for  an  Ada  exception  and 
makes  the  name  available  to  the  XD  Ada  Builder  as  a  global  symbol. 
Refer  to  the  XD  Ada  MC68020  Run-Time  Reference  Manual  for  further 
information  on  exporting  exceptions. 

Pragma  EXPORT.EXCEPTION  has  the  following  form: 

Fxaeaa  exPORT_excrPTION 

( lntarnal_naina  (,  external_deslqnator  ] 

(,  (TORM  ->)  ADA  I); 

The  internal  name  must  be  an  Ada  identifier  that  denotes  a  declared 
exception.  The  external  designator  denotes  an  XD  Ada  Builder  global 
symbol  to  be  used  to  refer  to  the  exception. 

The  form  option  specifies  that  an  Ada  exception  is  being  exported. 

Example: 

UNDERFLOW  t  aacaptioa 

prafsa  EXPORT^EXCEPTION  (UNDERFLOW,  HTH_UNDERFLOW,  ADA); 

In  this  example,  an  Ada  exception  is  exported  as  a  global  symbol. 
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13.10  Unchecked  Programming 


13.10.1  Unchecked  Storage  Deallocation 

The  following  information  supplements  the  Notes  section; 

Because  UNCHECKED.DEALLOCATION  is  a  predefined  generic  pro¬ 
cedure.  XD  Ada  does  not  allow  the  use  of  the  IMPORT_PROCEDURE 
pragma  to  substitute  an  alternative  procedure  body. 


13.10.2  Unchecked  Type  Conversions 

The  following  information  supplements  paragraph  2: 

XD  Ada  supports  the  generic  function  UNCHECKED_CONIVERSION 
with  the  following  restrictions  on  the  class  of  types  involved: 

•  The  actual  subtype  corresponding  to  the  formal  type  TARGET  must 
not  be  an  unconstrained  array  type. 

•  The  actual  subtype  corresponding  to  the  formal  type  TARGET  must 
not  be  an  unconstrained  type  with  discriminants. 

Further,  when  the  target  type  is  a  type  with  discriminants,  the  value 
resulting  from  a  call  of  the  conversion  function  resulting  from  an  instan¬ 
tiation  of  UNCHECKED.CONVERSION  is  checked  to  ensure  that  the 
discriminants  satisfy  the  constraints  of  the  actual  subtype. 

The  effect  with  XD  Ada  is  as  if  the  source  value  is  copied  one  byte 
in  ascending  order  of  address,  into  the  destination,  also  in  ascending 
order  of  address.  If  the  destination  has  fewer  bytes  than  the  source 
value,  the  high  order  bytes  of  the  source  value  are  ignored  (truncated). 
If  the  source  value  has  fewer  bytes  than  the  destination,  the  high  order 
bytes  of  the  destination  are  set  to  zero. 
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Chapter  13 

Representation  Clauses  and 
Implementation-Dependent 

Features 


This  chapter  describes  XD  Ada  MC68020  Version  1.2  interrupt  handling. 
In  particular,  it  describes  the  handling  of  direct  interrupt  entries,  and 
use  of  pragma  DIRECT_INTERRUPT_ ENTRY. 


13.5.1  Interrupts 

The  following  information  supplements  all  of  this  section: 

Unlike  VAX  Ada,  XD  Ada  supports  interrupts.  The  address  in  the  use 
clause  is  the  address  of  the  interrupt.  The  address  is  interpreted  as  an 
offset  in  bytes  from  the  vector  base  reeister.  For  details  of  MC68020 
exception  vector  assignments,  see  Table  6-2  of  the  MC68020  32-Bit 
Microprocessor  User's  Manual.  Note  that  when  assigning  vectors,  the 
offj  is  a  multiple  of  four  of  the  vector  number.  In  this  way,  vector 
numoer  64  (decimal)  would  have  the  hexadecimal  offset  100. 

In  addition  to  support  for  normal  Ada  interrupt  entries,  XD  Ada 
provides  the  additional  pragmas  LEVEL  and  DIRECT_INTERRUPT_ 
ENTTIY.  Pragma  LEVEL  is  given  for  a  task  type,  or  single  task  of  anony¬ 
mous  type,  and  gives  the  level  for  its  interrupts.  Pragma  DIRECT. 
INTERRUTT. ENTRY  is  used  to  connect  an  interrupt  entry  directly  to  the 
required  interrupt  vector,  and  is  described  below. 
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There  are  two  ways  an  interrupt  entry  can  be  handled,  according  to 
whether  or  not  the  task  has  a  pragma  LEVEL.  The  XD  Ada  MC68020 
Run-Time  Reference  Manual  gives  examples  of  interrupt  handlers. 

Tasks  with  interrupt  entries  but  no  pragma  LEVEL  run  at  interrupt  level 
0  only  while  accepting  an  interrupt  in  a  rendezvous.  Other  interrupts  of 
the  same  level  or  lower  levels  are  inhibited  while  in  the  handler.  It  is, 
however,  possible  to  lose  interrupts  with  this  method. 

Tasks  with  interrupt  entries  and  a  pragma  LEVEL  always  run  at  interrupt 
level,  whether  inside  or  outside  a  rendezvous.  This  enables  the  user  to 
avoid  losing  interrupts. 

An  interrupt  entry  to  a  task  with  the  pragma  LEVEL  behaves  like  an 
ordinary  entry  call.  An  interrupt  entry  to  a  task  with  no  pragma  LEVEL 
behaves  like  a  conditional  ent^  call.  If  there  is  an  accept  statement 
waiting  for  the  interrupt,  the  body  of  the  accept  statement  is  executed 
immediately.  When  the  body  is  complete,  the  task  is  inserted  in  the 
ready  queue  and  the  interrupt  completed  by  a  return-from-interrupt 
instruction.  The  accept  statement  can  call  subprograms  and  make  entry 
calls,  but  must  not  suspend  the  task  before  the  interrupt  is  dismissed, 
otherwise  the  program  repeatedly  services  the  interrupt  unsuccessfully. 

Writing  interrupt  handlers  in  XD  Ada  requires  detailed  knowledge  of 
the  behavior  of  the  target  computer's  interrupt  system.  It  is  not  possible 
simply  to  place  a  use  clause  on  an  entry  to  achieve  the  desired  effect. 

Normal  Ada  interrupt  entries  cause  a  tasking  reschedule  each  time  an 
interrupt  occurs.  This  inevitably  incurs  a  performance  overhead,  and 
may  mean  that  interrupts  are  not  serviced  quickly  enough.  In  order  to 
avoid  this  problem,  XD  Ada  supplies  pragma  DIRECT.INTERRUPT. 
ENTRY,  which  causes  the  interrupt  entry  to  be  connected  directly  to 
the  required  interrupt  vector.  This  run-time  efficiency  greatly  improves 
response  times.  The  form  of  this  pragma  is  as  follows: 

frmtmm  OIRK:T_tNT8R.*»'jPT_BNTRY(  interrupt_entry  I  ? 

Pragma  DIRECT. INTERRUPT. ENTRY  may  be  used  where  the  pro¬ 
gram  adheres  to  one  of  two  supported  code  models.  In  fact,  most 
applications  will  naturally  adhere  to  one  or  other  of  the  models,  so  the 
practical  restrictions  from  this  requirement  are  minimal.  The  use  of 
pragma  DIRECT.INTERRUPT.ENTRY  must  meet  certain  semantic  con¬ 
ditions.  These,  along  with  the  checks  carried  out  by  the  compiler  and 
run-time  system,  are  described  in  full  in  the  XD  Ada  MC68020  Run-Time 
Reference  Manual  part  of  this  manual. 
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Note  that  it  is  essential  that  the  lowest  level  direct  interrupt  (or  interrupt 
procedure)  is  always  higher  than  the  highest  level  normal  interrupt,  in 
order  that  the  direct  interrupt  context  is  not  left  as  a  result  of  interruptive 
preemption. 

The  models  and  the  related  conditions  are  described  in  full,  and  exam¬ 
ples  of  the  models  in  use  are  given,  in  the  XD  Ada  MC68020  Run-Time 
Reference  Manual  part  of  this  manual. 

Interrupt  procedures  and  Package  lNTERRUPT_SUPPORT  are  also 
described  in  the  XD  Ada  MC68020  Run-Time  Reference  Manual  part  of  this 
manual. 
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In  addition  to  the  standard  predefined  pragmas,  described  in  Annex  B 
of  the  Reference  Manual  for  the  Ada  Programming  Language,  XD  Ada  sup¬ 
ports  pragmas  CALL  SEQUENCE  FUNCTION,  CALL  SEQUENCE, 
PROCEDURE,  LINK,OPTION,  and  TITLE,  which  are  defined  here. 
This  annex  also  summarizes  the  definitions  given  elsewhere  of  the 
remaining  implementation-defined  pragmas. 

Oafinitlont 

CALL  SEQUENCE.FUNCnON 
CALL.SEQUENCE.PROCEDURE 

The  pragma  CALL_SEQUENCE_PROCEDURF  is  used  for  describing 
machine  code  insertions  or  exported  subprograms.  It  specifies  how 
parameters  are  mapped  onto  registers,  and  which  registers  must  be 
preserved,  for  machine  code  insertions  (see  Section  13.8).  The  pragma 
CALL.SEQUENCE.FUNCTION  is  also  provided.  These  pragmas  have 
the  form; 

ara«M  CALL_SEQUeNCB_FUNCTION 

(I  (UNIT  *>1  internal_name 
(,  (RESULT_TYPB  •>!  type_marlt  | 

(,  i PARAMETEB_TYPES  ->|  (  paranieter_typea  )  ) 

(,  (MECHANISM  »>|  mechanism  | 

(,  (RESULT_MECHAHISM  -> ]  mechanism_spec  ) 

(,  ( PRBSERVED_RBGISTBRS  ->  )  <  registers  >  ( 

); 

prafM  CAI.I._SeQUENCE_PROCEOURB 

((  (UNIT  ->|  internal_naiiie 
(,  ( PARAMETEB_TYPES  ->|  «  paraiTieter_typea  )  ) 

(,  (MECHANISM  ->J  mechanism  ) 

(,  ( pbESERVED_REGISTEBS  •>  )  (  registers  )  ) 

)! 
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parainecec_tYpe3 

•nil  T  type_marl«  (,  tvpe_mark) 
mechanism 

mechanlsm_spec  I  (  mechanism_spec  {,  mechanism_spec )  ) 
mechanism_spec 

m«chanism_nama  (  (  (REGISTER  ■>  |  reqlster_name  )  | 

m«chanism_name  t:> 
value”  I 

REFERENCE  j  BIT_REFERENCE  I 
OOPE_VECTOR  I  BIT”dOPE_VECTOR 

'•qistara  it- 

••11  I  reqi«t«r_naffl*  {,  reqiater_najn«  > 

Functions  must  be  identified  by  their  internal  names  and  parameter 
and  result  types.  The  parameter  and  result  types  can  be  omitted  only  if 
there  is  exactly  one  function  of  that  name  in  the  same  declarative  part  or 
package  specification.  Otherwise,  both  the  parameter  and  result  types 
must  be  specified. 

Procedures  must  be  identified  by  their  internal  names  and  parameter 
types.  The  parameter  types  can  be  omitted  only  if  there  is  exactly 
one  procedure  of  that  name  in  the  same  declarative  part  or  package 
specification.  Otherwise,  the  parameter  types  must  be  specified. 

The  parameter  types  option  specifies  a  series  of  one  or  more  type 
marks  (type  or  subtype  names),  not  parameter  names.  Each  type  mark 
is  positionally  associated  with  a  formal  parameter  in  the  subprogram's 
declaration.  The  absence  of  parameters  must  be  indicated  by  the 
reserved  word  null. 

The  result  type  option  is  used  only  for  functions;  it  specifies  the  type  or 
subtype  of  the  function  result. 

The  mechanism  option  specifies  how  the  imported  subprogram  expects 
its  parameters  to  be  passed  (for  example,  by  value,  by  reference  or 
by  descriptor).  The  calling  program  (namely  the  XD  Ada  program) 
is  responsible  for  ensuring  that  parameters  are  passed  in  the  form 
required  by  the  external  routine. 

If  the  first  form  of  the  mechanism  option  is  given  (a  single  mechanism 
name  without  parentheses),  all  parameters  are  passed  using  that  mech¬ 
anism.  If  the  second  form  is  given  (a  series  of  mechanism  names  in 
parentheses  and  separated  by  commas),  each  mechanism  name  de¬ 
termines  how  the  parameter  in  the  same  position  in  the  subprogram 
specification  will  be  passed.  With  the  second  form,  each  parameter 
name  must  have  an  associated  mechanism  name. 
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The  result  mechanism  option  is  used  only  for  functions;  it  specifies  the 
parameter-passing  mechanism  for  passing  the  result  type. 

Mechanism  names  are  described  in  Section  13.9a.l.l. 

The  preserved  registers  option  gives  a  list  of  hardware  registers  which 
are  not  altered  by  the  procedure  or  function.  If  this  option  is  omitted  it 
implies  that  no  registers  are  preserved;  in  this  case  the  effect  is  one  of 
the  following: 

•  If  the  body  of  the  subprogram  is  written  in  Ada,  the  compiler 
calculates  which  registers  are  preserved 

•  If  the  body  of  the  subprogram  is  a  machine  code  insertion,  the 
pragma  has  the  same  effect  as  pragma  IMPORT.PROCEDURE 


UNK.OPTION 

This  pragma  is  used  to  associate  link  option  file  names  with  a  program. 
Link  option  files  are  used  to  specify  the  target  and  mapping  definitions 
to  be  used  when  building  the  program.  In  this  way,  they  do  not  have 
to  be  explicitly  defined  on  the  XOACS  LINK  command  line.  The 
appropriate  external  target  and  mapping  definitions  (in  the  form  of  link 
option  files)  are  entered  into  the  program  library  by  use  of  the  XDACS 
command  COPY  LINK_0PT10N/F0REIGN,  as  described  in  Dn>eloping 
XD  Ada  Programs  on  VMS  Systems  for  the  MC68020.  If  a  suitable  link 
option  file  exists  in  another  program  library,  it  can  be  copied  to  the 
current  program  library  with  the  XDACS  command  COPY  LINK_ 
OPTION.  The  advantage  of  using  link  option  files  is  that  the  program 
definition  is  separate  from  the  program  itself,  and  so  can  be  altered 
without  making  the  last  compile  obsolete.  The  L1NK_0PT10N  pragma 
therefore  removes  the  need  to  recompile  the  whole  program.  More 
detail  on  this  topic  can  be  found  in  Sections  7.9  and  8.10  of  Developing 
XD  Ada  Programs  on  VMS  Systems  for  the  MC68020. 

Pragma  UNK.OPTION  has  the  form: 

prafM  LINK_OPTION(( 

(  (TARGiT->|link-option-f ile-nam*l 
I ,  (MAPPING«>)link-option-f ile-nane) 

li; 

This  pragma  is  only  allowed  in  the  outermost  declarative  part  of  a 
subprogram  that  is  a  library  unit;  at  most  one  such  pragma  is  allowed 
in  a  subprogram.  If  it  occurs  in  a  subprogram  other  than  the  main 
program,  this  pragma  has  no  effect  (see  Sections  9.8  and  9.9  (LRM)). 


Predefined  Language  Pragmas  B-3 


TITLE 


Takes  a  title  or  a  subtitle  string,  or  both,  in  either  order,  as  arguments. 

Pragma  TITLE  has  the  form: 

prayaa  TITLE  (titling-option 
[ , titling-option ) ) ; 

titling-option  :• 

(TITLE  ”>)  str ing_literal 
I  (SUBTITLE  ->)  atrlng_literal 

This  pragma  is  allowed  anywhere  a  pragma  is  allowed;  the  given  strings 

supersede  the  default  title  or  subtitle  portions  of  a  compilation  listing. 

Summary 

Pragma  Meaning 

EXPORT_EXCEPTION  Takes  an  internal  name  denoting  an 

exception,  and  optionally  takes  an 
external  designator  (the  name  of  an 
XD  Ada  Builder  global  symbol),  and 
a  form  (ADA)  as  arguments.  This 
pragma  is  only  allowed  at  the  place 
of  a  declarative  item,  and  must  apply 
to  an  exception  declared  by  an  earlier 
declarative  item  of  the  same  declara¬ 
tive  part  or  package  specification.  The 
pragma  permits  an  Ada  exception  to 
be  handled  by  programs  written  in  XD 
Ada  MC68020  assembly  language  (see 
Section  13. 9a. 3. 2). 

EXPORT.FUNCnON  Takes  an  internal  name  denoting  a 

function,  and  optionally  takes  an  ex¬ 
ternal  designator  (the  name  of  an  XD 
Ada  Builder  global  symbol),  parameter 
types,  and  result  type  as  arguments. 

This  pragma  is  only  allowed  at  the  place 
of  a  declarative  item,  and  must  apply 
to  a  function  declared  by  an  earlier 
declarative  item  of  the  same  declara¬ 
tive  part  or  package  specification.  In 
the  case  of  a  function  declared  as  a 
compilation  unit,  the  pragma  is  only 
allowed  after  the  function  declaration 
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EXPORT_OBJECT 


EXPORT.PROCEDURE 


and  before  any  subsequent  compilation 
unit.  This  pragma  is  not  allowed  for  a 
function  declared  with  a  renaming  dec¬ 
laration,  and  is  not  allowed  for  a  generic 
function  (it  can  be  given  for  a  generic 
instantiation).  This  pragma  permits  an 
Ada  function  to  be  called  from  a  pro¬ 
gram  written  in  assembly  language  (see 
Section  13. 9a.  1.2). 

Takes  an  internal  name  denoting  an 
object,  and  optionally  takes  an  exter¬ 
nal  designator  (the  name  of  an  XD  Ada 
Builder  global  symbol),  and  size  des¬ 
ignator  as  arguments.  This  pragma  is 
only  allowed  at  the  place  of  a  declarative 
item  at  the  outermost  level  of  a  library 
package  specification  or  body,  and  must 
apply  to  a  variable  declared  by  an  earlier 
declarative  item  of  the  same  package 
specification  or  body;  the  variable  must 
be  of  a  type  or  subtype  that  has  a  con¬ 
stant  size  at  compile  time.  This  pragma 
is  not  allowed  for  objects  declared  with  a 
renaming  declaration,  and  is  not  allowed 
in  a  generic  unit.  This  pragma  permits 
an  Ada  object  to  be  referred  to  by  a 
routine  written  in  assembly  language  (see 
Section  13.9a.2.2). 

Takes  an  internal  name  denoting  a  pro¬ 
cedure,  and  optionally  takes  an  external 
designator  (the  name  of  an  XD  Ada 
Builder  global  symbol),  and  parameter 
types  as  arguments.  This  pragma  is  only 
allowed  at  the  place  of  a  declarative  item, 
and  must  apply  to  a  procedure  declared 
by  an  earlier  declarative  item  of  the  same 
declarative  part  or  package  specification. 
In  the  case  of  a  procedure  declared  as 
a  compilation  unit,  the  pragma  is  only 
allowed  after  the  procedure  declaration 
and  before  any  subsequent  compilation 
unit.  This  pragma  is  not  allowed  for 
a  procedure  declared  with  a  renaming 
declaration,  and  is  not  allowed  for  a 
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generic  procedure  (it  may  be  given  for 
a  generic  instantiation),  this  pragma 
permits  an  Ada  routine  to  be  railed  from 
a  program  written  in  assembly  language 
(see  Section  13.9a.  1.2). 

IMPORT_EXCEPTION  Takes  an  internal  name  denoting  an 

exception,  and  optionally  takes  an  ex¬ 
ternal  designator  (the  name  of  an  XD 
Ada  Builder  global  symbol),  and  a  form 
(ADA)  as  arguments.  This  pragma  is 
only  allowed  at  the  place  of  a  declarative 
item,  and  must  apply  to  an  exception 
declared  by  an  earlier  declarative  item 
of  the  same  declarative  part  or  package 
specification.  The  pragma  is  included  for 
compatibility  with  VAX  Ada  (see  Section 
13.9a.3.1). 

IMPORT_FUNCTION  Takes  an  internal  name  denoting  a  func¬ 

tion,  and  optionally  takes  an  external 
designator  (the  name  of  an  XD  Ada 
Builder  global  symbol),  parameter  types, 
and  result  type  as  arguments.  Pragma 
INTERFACE  must  be  used  with  this 
pragma  (see  Section  13.9).  This  pragma 
is  only  allowed  at  the  place  of  a  declar¬ 
ative  item,  and  must  apply  to  a  function 
declared  by  an  earlier  declarative  item 
of  the  same  declarative  part  or  package 
specification.  !n  the  case  of  a  func¬ 
tion  declared  as  a  compilation  unit,  the 
pragma  is  only  allowed  after  the  function 
declaration  and  before  any  subsequent 
compilation  unit.  This  pragma  is  allowed 
for  a  function  declared  with  a  renaming 
declaration;  it  is  not  allowed  for  a  generic 
function  or  a  generic  function  instantia¬ 
tion.  This  pragma  permits  an  assembly 
language  routine  to  be  used  as  an  Ada 
function  (see  Section  13.9a.l.l). 
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Takes  an  internal  name  denoting  an 
object,  and  optionally  takes  an  external 
designator  (the  name  of  an  XD  Ada 
Builder  global  symbol),  as  arguments. 
This  pragma  is  only  allowed  at  the  place 
of  a  declarative  item  at  the  outermost 
level  of  a  library  package  specification 
or  body,  and  must  apply  to  a  variable 
declared  by  an  earlier  declarative  item  of 
the  same  package  specification  or  body; 
the  variable  must  be  of  a  type  or  subtype 
that  has  a  constant  size  at  compile  time. 
This  pragma  is  not  allowed  for  objects 
declared  with  a  renaming  declaration, 
and  is  not  allowed  in  a  generic  unit.  This 
pragma  permits  storage  declared  in  an 
assembly  language  routine  to  be  referred 
to  by  an  Ada  program  (see  Section 
13.9a.2.1). 

Takes  an  internal  name  denoting  a 
procedure,  and  optionally  takes  an  ex¬ 
ternal  designator  (the  name  of  an  XD 
Ada  Builder  global  symbol),  and  pa¬ 
rameter  types  as  arguments.  Pragma 
INTERFACE  must  be  used  with  this 
pragma  (see  Section  13.9).  This  pragma 
is  only  allowed  at  the  place  of  a  declara¬ 
tive  item,  and  must  apply  to  a  procedure 
declared  by  an  earlier  declarative  item 
of  the  same  declarative  part  or  pack¬ 
age  specification.  In  the  case  of  a 
procedure  declared  as  a  compilation 
unit,  the  pragma  is  only  allowed  after 
the  procedure  declaration  and  before 
any  subsequent  compilation  unit.  This 
pragma  is  allowed  for  a  procedure  de¬ 
clared  with  a  renaming  declaration;  it  is 
not  allowed  for  a  generic  procedure  or 
a  generic  procedure  instantiation.  This 
pragma  permits  an  assembly  language 
routine  to  be  used  as  an  Ada  procedure 
(see  Section  i3.9a.l.l). 
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INTERFACE 

LEVEL 

STORAGE.UNIT 

SUPPRESS.ALL 

VOLATILE 


In  XD  Ada,  pragma  INTERFACE  is 
required  in  combination  with  pragmas 
IMPORT  FUNCTION  and  IMPORT. 
PROCEDURE  (see  Section  13.9a.  1). 

This  pragma  identifies  a  task  or  task  type 
as  running  at  interrupt  level.  Pragma 
LEVEL  has  one  argument  specifying 
the  level  for  its  interrupts  (see  Section 
13.5.1). 

In  XD  Ada,  the  only  argument  allowed 
for  this  pragma  is  8. 

This  pragma  has  no  argument  and  is 
only  allowed  following  a  compilation 
unit.  This  pragma  specifies  that  all  run¬ 
time  checks  in  the  unit  are  suppressed 
(see  Section  11.7). 

Takes  the  simple  name  of  a  variable 
as  the  single  argument.  This  pragma 
is  only  allowed  for  a  variable  declared 
by  an  object  declaration.  The  variable 
declaration  and  the  pragma  must  both 
occur  (in  this  order)  immediately  within 
the  same  declarative  part  or  package 
specification.  The  pragma  must  appear 
before  any  occurrence  of  the  name  of 
the  variable  other  than  in  an  address 
clause  or  in  one  of  the  XD  Ada  pragmas 
IMPORT.OBJECT  or  EXPORT.OBJECT. 
The  variable  cannot  be  declared  by  a 
renaming  declaration.  The  VOLATILE 
pragma  specifies  that  the  variable  may  be 
modified  asynchronously.  This  pragma 
instructs  the  compiler  to  obtain  the  value 
of  a  variable  from  memory  each  time  it 
is  used  (see  Section  9.11). 
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